Stories
Slash Boxes
Comments

SoylentNews is people

posted by Fnord666 on Sunday May 10 2020, @06:47PM   Printer-friendly
from the stormy-weather dept.

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/fstab or as actual .mount units.

[*] 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


Original Submission

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 3, Informative) by NCommander on Sunday May 10 2020, @07:30PM (13 children)

    by NCommander (2) Subscriber Badge <michael@casadevall.pro> on Sunday May 10 2020, @07:30PM (#992503) Homepage Journal

    upstart was the same basic idea (as an init/mount manager) that was considerably less of a problem. I do count mounting disks to be an init issue because it was an endless source of bug reports especially in cases where NFS was in play (SysV automount can go die in a fire). We had issues with it here on SN when we briefly tried NFS for site deployment; it was an utter mess (we used gluster, before just deciding to rsync the entire /srv/soylentnews.org folder which was a brute force approach)

    If systemd was content to stay as an init process, I'd live with it. The fact that provides relatively little benefit and major pain has soured me on it. At least Ubuntu still keeps the text logs around in addition to journalctl.

    --
    Still always moving
    Starting Score:    1  point
    Moderation   +1  
       Informative=1, Total=1
    Extra 'Informative' Modifier   0  
    Karma-Bonus Modifier   +1  

    Total Score:   3  
  • (Score: 5, Insightful) by canopic jug on Sunday May 10 2020, @07:46PM (12 children)

    by canopic jug (3949) Subscriber Badge on Sunday May 10 2020, @07:46PM (#992507) Journal

    I agree about Upstart being a better choice, but it is not an apt comparison. Upstart [darknedgy.net] was an init system. systemd is not an init system [darknedgy.net], though I can see where the confusion comes from. Poettering and his fanbois had been and continue be misrepresenting systemd as an init system.

    In short, they lie about it. That's no surprise as the two other methods of promoting it have been appeals to novelty and personal attacks. The real puzzle is the Debian Technical Committee vote. The tie-breaking vote picked systemd even though it was fourth place and three more popular options were ahead of it. Then the whole project just folder and acquiesced without even any grumbling and, with that, hundreds of derivative distros fell to systemd. Then Poettering and his fanbois could add the false claim that systemd was popular, rather than a more accurate claim of being widely deployed because the downstream distros had little to no choice. Devuan and the few other free distros do a lot of clean up, that is a lot of effort not spent in other ways making the distros and packages better. Of those, I was most disappointed in the fact that there was neither pushback from Canonical over this move from Red Hat nor did they move their base from Debian to Devuan as they could have done. However, by that time Canonical already had "former" microsofters on staff. probably eager to throw systemd sand in the gears.

    --
    Money is not free speech. Elections should not be auctions.
    • (Score: 5, Informative) by NCommander on Sunday May 10 2020, @07:53PM (3 children)

      by NCommander (2) Subscriber Badge <michael@casadevall.pro> on Sunday May 10 2020, @07:53PM (#992512) Homepage Journal

      The Technical Committee vote is a serious sore point for me, but I can't go into details as most of it was on debian-private. I can't blame Canonical for switching to systemd when Debian did due to the burden it would have caused, but I put more of the blame on Red Hat who have a long history of shoving shit down the communities throat and forcing people to accept it.

      Red Hat was the reason we had to put up with Ulrich Drepper and the utter nightmare of glibc development until he was forked around with eglibc.

      Disclaimer: I was employed by Canonical at the time, and was a Debian Developer.

      --
      Still always moving
      • (Score: 0) by Anonymous Coward on Monday May 11 2020, @12:52AM

        by Anonymous Coward on Monday May 11 2020, @12:52AM (#992580)

        Do you recommend an inquiry?

      • (Score: 2, Interesting) by Anonymous Coward on Monday May 11 2020, @09:16PM

        by Anonymous Coward on Monday May 11 2020, @09:16PM (#993085)

        If Debian forgot one of the main points to exist was caring about their users, maybe it is time for some whistleblowing. Not you, just dropping the idea.

        Or the more polite enquire suggested above. But I guess transparency and accountability are just words in the dictionary, not to be applied in real world.

      • (Score: 1, Informative) by Anonymous Coward on Monday May 11 2020, @09:52PM

        by Anonymous Coward on Monday May 11 2020, @09:52PM (#993097)

        Thanks for the veiled insight. Consolations.

    • (Score: 5, Interesting) by Anonymous Coward on Sunday May 10 2020, @09:56PM (2 children)

      by Anonymous Coward on Sunday May 10 2020, @09:56PM (#992533)

      On the Arch Linux forums when systemd was first brought up, the "official" maintainers (whatever that means) stated that they didn't wanna support multiple init systems so they'd be moving to it.

      A handful of people volunteered to support the existing init system in parallel. They were directed to a separate subforum then banned.

      That was my first warning sign that this systemd thing might be something I'd want to avoid.

      • (Score: 0) by Anonymous Coward on Thursday May 14 2020, @12:42AM

        by Anonymous Coward on Thursday May 14 2020, @12:42AM (#994038)

        I was there when that happened, I can confirm. And it was what drove me away from Arch, even though I was very happy with it at the time. I'm glad I found Void, it makes for a great systemd-free alternative to Arch. A little drama these past few weeks but nothing the maintainers can't work around.

      • (Score: 0) by Anonymous Coward on Tuesday May 26 2020, @11:59AM

        by Anonymous Coward on Tuesday May 26 2020, @11:59AM (#999170)

        Seems similar to Poettering engineered the transition from consolekit to logind.

        Get himself assigned maintainership, hand Gnome a patch set to support logind on a silver platter, then send out a terse email declaring consolekit deprecated and redirect all replies to /dev/null.

        Even better is that systemd-logind overriding nohup came about because Gnome failed to clean up its session on logout.

        Oh, and su is apparently a big nono with systemd. Instead you should use ssh to 127.0.0.1 if you need a root prompt.

        I swear the guy has Apple envy, yet keep recreating Windows piece by piece. Do wonder how long before he joins Icaza at Redmond. Probably not long after Microsoft declares its own Linux distro with a Win32 compatibility layer.

    • (Score: 2) by https on Sunday May 10 2020, @10:24PM

      by https (5248) on Sunday May 10 2020, @10:24PM (#992544) Journal

      When you suggest that

      the whole project just folder and acquiesced without even any grumbling

      ...clearly, you were not subscribed to debian-devel.

      Never heard such a load of whining until it was shown that Trump is masturbating to burning copies of the constitution.

      --
      Offended and laughing about it.
    • (Score: 0) by Anonymous Coward on Monday May 11 2020, @06:24AM

      by Anonymous Coward on Monday May 11 2020, @06:24AM (#992699)

      Still, the commonly cited advantage of systemd unit files being ‘declarative’ is hard to square with its dependency model not allowing you to think in term of ‘goals’, ‘constraints’ and ‘invariants’ as you would expect from declarative programming. I’ve noticed that nowadays ‘declarative’ gets stretched to refer to just about any simple configuration language that doesn’t have explicit control flow constructs, which would make the term completely trivial.

      I haven't been able to put into words my main problem with systemd or modern declarative DSLs. It was nice to finally put my finger on both in the same time.

    • (Score: 2) by Thexalon on Monday May 11 2020, @12:45PM (2 children)

      by Thexalon (636) on Monday May 11 2020, @12:45PM (#992785)

      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

        by Anonymous Coward on Tuesday May 12 2020, @02:25AM (#993203)

        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

        by Anonymous Coward on Tuesday May 26 2020, @12:04PM (#999172)

        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.