Stories
Slash Boxes
Comments

SoylentNews is people

posted by janrinok on Tuesday August 19 2014, @12:04PM   Printer-friendly
from the you-either-love-it-or-hate-it dept.

The good people over at Infoworld have published a story outlining why they feel systemd is a disaster.

Excerpt from Infoworld:

While systemd has succeeded in its original goals, it's not stopping there. systemd is becoming the Svchost of Linux—which I don't think most Linux folks want. You see, systemd is growing, like wildfire, well outside the bounds of enhancing the Linux boot experience. systemd wants to control most, if not all, of the fundamental functional aspects of a Linux system—from authentication to mounting shares to network configuration to syslog to cron. It wants to do so as essentially a monolithic entity that obscures what's happening behind the scenes.

 
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: 4, Insightful) by MrNemesis on Tuesday August 19 2014, @02:57PM

    by MrNemesis (1582) on Tuesday August 19 2014, @02:57PM (#83103)

    This is what, to me, a mostly server-only user, is so bloody annoying about systemd. It seems to be primarily only beneficial to desktop users, although I've never seen the boot process (excluding applications) take longer than 30s since I started using SSDs in 2009.

    A new init system that's better suited for desktop tasks? Absolutely brilliant, great, fantastic! Super quick boot, parallel startup, event-based doohickeys... superb.

    But even on the server, where most of the benefits of systemd are non-existent from my PoV, this is being forced down people's throats as it's become the *only* supported init because it seems to have been designed to not just stick its fingers in all the pies but to make all other pies untouchable by non-systemd fingers and inedible by non-systemd digestive tracts. It tries it's hardest to push you towards a binary log format (bye-bye grep, tail and all t'other friendly tools - thankfully debian still seem to be using systemd as a mere passthrough to standard logging tools) and a boot process that, when it fails, fails hard and requires /usr being immediately available post-initramfs (lots of servers use a shared read-only /usr over NFS). The binary log thing is especially stupidly onerous - the only secure way to avoid log tampering (apparently the sole justification behind the binary log format) is to have your logs duped off to a couple of remote syslog servers, if your box is compromised then yes, shock horror, even binary log files can be tampered with and thus can't be relied on. So IMHO the whole binary log thing is a non-solution in search of a problem that's already impossible to solve on a single system.

    On top of that, there seem to be a whole distro's worth of stupid camel-cased'd replacements for network, cron, NTP, fstab and all the other baseline system functions coming down the pipeline that I don't think should have anything to do with init. svchostd for linux indeedd.

    Even for my "desktop" machines (mostly a couple of HTPC builds), the improvement in boot time is negligible, and dwarfs into comparison with application startup time. I benched this with my HTPC running on a DH77DF, debian jessie; BIOS boot + SysV init went from power button to desktop in 10s. UEFI boot + systemd takes that down to 7s. Large enough to be noticeable but not enough to make any real difference (it takes longer for the screen to come out of standby). Resume from S3 is instantaneous regardless of the init system used.

    Now I know this all sounds like "stupid old neckbeard wants linux on the desktop to suck" but I've still not seen a good reason why systemd can't co-exist with older, slower but more flexible inits.

    *shrugs*

    --
    "To paraphrase Nietzsche, I have looked into the abyss and been sick in it."
    Starting Score:    1  point
    Moderation   +2  
       Insightful=1, Informative=1, Total=2
    Extra 'Insightful' Modifier   0  
    Karma-Bonus Modifier   +1  

    Total Score:   4  
  • (Score: 1, Flamebait) by evilviper on Tuesday August 19 2014, @05:47PM

    by evilviper (1760) on Tuesday August 19 2014, @05:47PM (#83185) Homepage Journal

    systemd. It seems to be primarily only beneficial to desktop users

    Most of systemD's improvements benefit servers, not desktop users.

    Tracking service startup dependencies and ordering/waiting for things correctly.

    Automatically just restarting any service that crashes.

    Improving syslog.

    etc.

    Those are all things any admin would kill for, that has always been such a half-assed mess. Debugging a system, and/or rebooting it every time it comes up and a network file system didn't mount in-time... Getting paged at 3AM every day, because after 2 years of uptime, crond happened to crash and across hundreds of servers, it's a daily occurrence... etc. These are all very important to any server admins, and hardly matter to desktop users.

    --
    Hydrogen cyanide is a delicious and necessary part of the human diet.
    • (Score: 1, Insightful) by Anonymous Coward on Tuesday August 19 2014, @06:25PM

      by Anonymous Coward on Tuesday August 19 2014, @06:25PM (#83196)

      Most of systemD's improvements benefit servers, not desktop users.

      This is not the opinion of any server admin I've spoken with.

      Tracking service startup dependencies and ordering/waiting for things correctly.

      This was never an issue until parallel startup - boot times remain insignificant on servers. Would you thank the guy who boards up your window when you just witnessed him smash it?

      Automatically just restarting any service that crashes.

      That isn't a 'feature'. On a networked server or multi user machine I want a crashed daemon to stay that way until I have investigated.

      Improving syslog.

      If that was their intent they failed completely. As the GP explained, log tampering can only be fixed by logging to a remote machine. Binary log formats do not solve that problem, least of all when log corruption is considered not a bug [freedesktop.org]

      Those are all things any admin would kill for, that has always been such a half-assed mess. Debugging a system, and/or rebooting it every time it comes up and a network file system didn't mount in-time... Getting paged at 3AM every day, because after 2 years of uptime, crond happened to crash and across hundreds of servers, it's a daily occurrence... etc. These are all very important to any server admins, and hardly matter to desktop users.

      Sure - it's "a daily occurrence" "after 2 years of uptime" "across hundreds of servers" - but apparently only for you! I've not noticed this, perhaps I need to change my medication or I just selectively forget these incidents whilst vividly remembering dealing with hard drives that burst into flames and shit?

    • (Score: 5, Insightful) by MrNemesis on Tuesday August 19 2014, @08:33PM

      by MrNemesis (1582) on Tuesday August 19 2014, @08:33PM (#83237)

      Well, the AC above has already said most of what I was going to say but here's my slightly-differently-worded take on it.

      Most of systemD's improvements benefit servers, not desktop users.

      An impenetrable boot process does not benefit servers. Needing /usr available after initrd does not benefit servers... unless of course having /usr over NFS is "holding it wrong". Even on slow-arse 2x7200rpm RAID1's, bootup time is about 10% of what POST time is... well, OK, 20% of PST time if this is a throwaway dev physical and you're cheaping out on softraid. Boot time on a server, as long as it's under a few minutes, is an utterly meaningless metric in my world. Even using appallingly stone-aged SysV init our virtuals boot in less than 30s, out physicals POST in 5mins... and boot for 30s.

      Tracking service startup dependencies and ordering/waiting for things correctly.

      Maybe I'm just being stupid, but distros seem to have already made this a solved problem since forever ago. It's almost as if init had a concept of the varying levels at which things should run... I forget what it's called... jogfloors? Saunterplanes? Scamperdecks? Dash-storeys? Scurrytiers?

      Automatically just restarting any service that crashes.

      Like the AC, there's no way in hell you'd do this in our environment, and it's frowned on in windows as well other than for *really* flaky services that would generate excessive amounts of admin overhead otherwise (and already have exceptions in place for escalations). Our "important" prod boxes have some vastly expensive software on them to fulfil this purpose, our non-important boxes use common tools like monit (does the same thing but without the supposed benefit of a support contract)... but *none* of them will just restart a service without reporting it, judging impact and escalating if need be. For most important systems, if a daemon fails one of the other servers takes over services until the duty engineer(s) can have a look at it and explain why it fell over in the first place - half the time when a service does fall over it's because of a non-transient error, so restarting will just lead to another crash and this achieves nothing but filling up your inbox and making your line manager have a minor freakout. Isolate the box and bring the service up elsewhere. Linux is one of the few OS'es where that's *easy*.

      Improving syslog.

      There's nothing improved against bog standard syslog that I can see. In fact, it's gone backwards. It's *less* useful on a systemd/journald system because you can't use standard tools to read it. When boot fails I don't even get to see a log.

      Those are all things any admin would kill for, that has always been such a half-assed mess. Debugging a system...

      Well, we don't keep our systems up for 2yrs at a time for a start, we reboot at the very longest at least once a month and yet we're still somehow at over five nines for the last three years. RHEL and debian system updates and admins tinkering with various bits of the system are still frequent enough that you're better of testing the server comes up cleanly on a very regular basis, not when you're forced to by seventeen pending kernel updates. We've never had a "half-assed mess"; hey, if the NFS mount doesn't come up in time the boot process waits until it does, if it takes 2x longer than it usually does then the duty engineer gets a beep and if it takes more than 10mins the duty engineer is going to get several loud phone calls from the escalation engineers. But... lo and behold... that almost never happens, and when it does it's always been due to hardware failure rather than services starting in the wrong order. Like AC said... parallel startup might solve problems on the desktop but for servers it's inconsequential when it doesn't happen and frequently problematic when it does.

      So... again... in the server space at least, what problems is it that systemd's solving that haven't already been solved?

      --
      "To paraphrase Nietzsche, I have looked into the abyss and been sick in it."
      • (Score: 0) by Anonymous Coward on Tuesday August 19 2014, @11:38PM

        by Anonymous Coward on Tuesday August 19 2014, @11:38PM (#83291)

        Thank you. I'm far too busy and annoyed over the purported benefits (ie: coprophagia - "it's good for you") of systemd to move beyond heart-felt if sarcasm laced rebuttals. I hope your reasoned technical explanation of the real-world problems we face will result in the faces of a few people flushing the same color as their hat ;P