from the fed-up-with-the-UNIX-take-over dept.
The spreading of systemd continues, now actively pushed by themselves unto other projects, like tmux:
"With systemd 230 we switched to a default in which user processes started as part of a login session are terminated when the session exists (KillUserProcesses=yes).
[...] Unfortunately this means starting tmux in the usual way is not effective, because it will be killed upon logout."
It seems methods already in use (daemon, nohup) are not good for them, so handling of processes after logout has to change at their request and as how they say. They don't even engange into a discussion about the general issue, but just pop up with the "solution". And what's the "reason" all this started rolling? dbus & GNOME coders can't do a clean logout so it must be handled for them.
Just a "concidence" systemd came to the rescue and every other project like screen or wget will require changes too, or new shims like a nohup will need to be coded just in case you want to use with a non changed program. Users can probably burn all the now obsolete UNIX books. The systemd configuration becomes more like a fake option, as if you don't use it you run into the poorly programmed apps for the time being, and if they ever get fixed, the new policy has been forced into more targets.
Seen at lobsters 1 & 2 where some BSD people look pissed at best. Red Hat, please, just fork and do you own thing, leaving the rest of us in peace. Debian et al, wake up before RH signed RPMs become a hard dependency.
System adminsitrator Chris Siebenmann has found Modern versions of systemd can cause an unmount storm during shutdowns:
One of my discoveries about Ubuntu 20.04 is that my test machine can trigger the kernel's out of memory killing during shutdown. My test virtual machine has 4 GB of RAM and 1 GB of swap, but it also has 347 NFS[*] mounts, and after some investigation, what appears to be happening is that in the 20.04 version of systemd (systemd 245 plus whatever changes Ubuntu has made), systemd now seems to try to run umount for all of those filesystems all at once (which also starts a umount.nfs process for each one). On 20.04, this is apparently enough to OOM[**] my test machine.
[...] Unfortunately, so far I haven't found a way to control this in systemd. There appears to be no way to set limits on how many unmounts systemd will try to do at once (or in general how many units it will try to stop at once, even if that requires running programs). Nor can we readily modify the mount units, because all of our NFS mounts are done through shell scripts by directly calling
mount; they don't exist in
/etc/fstabor as actual
We've been here before and there is certainly more where that came from.
(2020) Linux Home Directory Management is About to Undergo Major Change
(2019) System Down: A systemd-journald Exploit
(2017) Savaged by Systemd
(2017) Linux systemd Gives Root Privileges to Invalid Usernames
(2016) Systemd Crashing Bug
(2015) tmux Coders Asked to Add Special Code for systemd
(2016) SystemD Mounts EFI pseudo-fs RW, Facilitates Permanently Bricking Laptops, Closes Bug Invalid
(2015) A Technical Critique of Systemd
(2014) Devuan Developers Can Be Reached Via firstname.lastname@example.org
(2014) Systemd-resolved Subject to Cache Poisoning