SoylentNews is people
SoylentNews
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.mountunits.
[*] NFS: Network File System
[**] OOM Out of memory.
We've been here before and there is certainly more where that came from.
Previously:
(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 vua@debianfork.org
(2014) Systemd-resolved Subject to Cache Poisoning
(Score: 2) by Thexalon on Monday May 11 2020, @12:45PM (2 children)
The pattern of systemd adoption has always had me wondering whether its supporters had non-technical motivation for using it, i.e. bribes or threats.
The only thing that stops a bad guy with a compiler is a good guy with a compiler.
(Score: 0) by Anonymous Coward on Tuesday May 12 2020, @02:25AM
Based on what I've seen first hand, heard about second hand, and read reliable accounts of, in regards to microsoft products and specifications, I'd say that it is a matter of a few well-placed, credible threats now and again. systemd is not from microsoft but it is about high stakes control over global communication. If groups play hardball like that over the desktops, they're going to be even more wicked for a chance at control over the larger market consisting of everything else.
(Score: 0) by Anonymous Coward on Tuesday May 26 2020, @12:04PM
Threats basically, and ever so oftne getting their guy to take over maintainership before running the project into the ground (Poettering basically did that with consolekit before rolling out systemd-logind).
There is a story floating around about docker devs and RH devs having a spat, where the Docker devs told RH to pound sand regarding some changes they wanted. Soon after RH started talking up systemd-nspawn as a Docker replacement.
It is the same kind of behavior one has seen from both Apple and Microsoft over the years, where they would either buy out or roll out a competitor for a successful piece of software on their respective platforms.