Comment by epistasis

Long emotional rant ahead, you have been warned. The poorly thought out adoption of parts of systemd, and in particular systemd-oomd, are making me yearn for FreeBSD.

For all my computing career, I'd use Unix-alike because they let me develop software by having an idea, write some code, let it run in the terminal, chain things together, and see where it failed, and iterate. Terminals let this happen much faster than clicky GUI software, and contain a log of what was happening in a terminal pane (or gnus screen or tmux pane, because usually this is happening on big servers and compute clusters rather than my terminal/laptop)

I could launch a bunch of panes, have several lines of investigation going, and come back to it a day or week later when I had time because the terminal kept a log of everything that happened.

And a couple years ago I started noticing that things I thought I had launched would start disappearing. At first I thought I had started accidentally mispressing a key and killing a tmux pane rather than disconnecting.

But no! When I finally went back to a in-person Linux workstation and saw it happen to the entire terminal window, I knew something major had changed. It turns out that something called systemd-oomd was added to a bunch of distributions that now kills only entire cgroups of processes at a time, rather than a single process offender.

So now if you want to run processes and isolate the kill zone of a process, you have to wrap every freaking subprocess in an entire systemd-run wrapper or docker wrapper. And systemd-run won't work from many contexts, such as inside a Jupyter kernel.

Major breaking changes on fundamental system behavior are a huge problem these days. It's one thing to let the OS kill processes more when there's a memory issue, fine, great, go ahead. But why kill all the lightweight processes that could give feedback to a user?! And why force non-portable process launching semantics, that aren't even consistent across the entire system?!? So infuriating.