earlyoom VS systemd

EarlyOOM [1] could help with that quite a lot. Not to sure about using it on chromebooks, but linux got quite a bit more usable because of it.

[1] https://github.com/rfjakob/earlyoom

> The system is not supposed to 'lock up' when you run out of physical RAM. If it does, something is wrong. It might become slower as pages are flushed to disk but it shouldn't be terrible unless you are really constrained and thrashing. If the Kernel still can't allocate memory, you should expect the OOMKiller to start removing processes. It should not just 'lock up'. Something is wrong.

I don't why but locking up is my usual experience for Desktop Linux for many years and distros, and I remember seeing at least one article explaining why. The only real solution is calling the OOMKiller early either with a daemon or SysRq.

> It should not take minutes. Should happen really quickly once thresholds are reached and allocations are attempted. What is probably happening is that the system has not run out of memory just yet but it is very close and is busy thrashing the swap. If this is happening frequently you may need to adjust your settings (vm.overcommit, vm.admin_reserve_kbytes, etc). Or even deploy something like EarlyOOM (https://github.com/rfjakob/earlyoom). Or you might just need more RAM, honestly.

Yeah. Exactly. But as the thread says, why aren't those things set up automatically?

It's not that simple: some defaults may differ, and some features may arrive at different times (if ever). For example, earlyoom has been enabled on Workstation since F32, but the KDE Plasma spin got it one release later.

Most answers will answer your question, but you can do better and avoid the freezes in the first place. IME almost every time the system froze up and didn't come back in a few seconds it was out of memory. The obvious solution is to add memory, but you can use Early OOM to kill hungry processes if you're running out of memory instead.

It sounds like you're running out of memory though, so if your OS's OOM killer isn't working as well as it should, you can try earlyoom as an alternative.

https://github.com/systemd/systemd/issues/6129#issuecomment-...

"core: add RestartSteps= and RestartSecMax= to dynamically increase interval between auto restarts"

I ran into this issue on an embedded system before it was raised / fixed:

https://github.com/systemd/systemd/issues/8398

FWIW, I'm generally a fan of systemd. That's a pretty minor issue in the grand scheme of things and it's not really "mysterious" -- the behaviour was consistent but didn't line up with the documentation.

In my experience, almost every time I hit an issue with systemd, it's when I'm interacting with it at a (relatively) low level. e.g. Monitoring / controlling units via D-Bus. There is theoretically enough documentation to do that, but it's often incomplete or ambiguous and you're left trying to figure out systemd's behaviour via experimentation.

But as I said, this isn't _really_ a dig against systemd. Even if monitoring service state transitions via D-Bus is finnicky, it's a heck of a lot easier than the alternatives with busybox init or whatever.

> Primarily append-based, hence robust to corruption

It's so robust, it doesn't even let you modify the journal if you want to (e.g. https://github.com/systemd/systemd/issues/20673).

> Support for in-line compression

Mind that journald only supports compressing single lines, but not the whole journal (https://github.com/systemd/systemd/issues/31358), which is pretty limiting.

https://github.com/systemd/systemd/pull/33383

Or that time that systemd mounted efivarfs as rw making it possible to brick your motherboard

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...

Or the time back around 2012ish when an update caused the dhcp lease renewal portion to get wedged and took many thousands of servers offline until the service could be manually restarted or the machine rebooted.

Or there was that time when OpenSSH was compromised because they pulled in systemd components to handle notifications:

> You can use "keyscript=" in "/etc/crypttab" to run any script you want.

...unless your distro uses systemd, which removes keyscript support [1] because the systemd guy "really dislikes generic callouts"

[1] https://github.com/systemd/systemd/pull/3007

> What are you talking about???

This: https://github.com/systemd/systemd/blob/main/docs/ELF_DLOPEN...

> dlopen is hardly a new "delayed loading mechanism"

Yes, it's a well-known anti-pattern that libraries like glibc are trying to minimize.

When your fuckup requires a change in the basic system architecture, you are probably doing it wrong.

_All_ they needed to do was split libsystemd into libcoresystemd and libjournald. Only the latter requires libxz and other compressors.