Skip Navigation
Linux @lemmy.ml
Nuuskis @sopuli.xyz

Is Systemd that bad afterall?

SystemD is blamed for long boot times and being heavy and bloated on resources. I tried OpenRC and Runit on real hardware (Ryzen 5000-series laptop) for week each and saw only 1 second faster boot time.

I'm old enough to remember plymouth.service (graphical image) being the most slowest service on boot in Ubuntu 16.04 and 18.04. But I don't see that as an issue anymore. I don't have a graphical systemD boot on my Arch but I installed Fedora Sericea and it actually boots faster than my Arch despite the plymouth (or whatever they call it nowadays).

My 2 questions:

  1. Is the current SystemD rant derived from years ago (while they've improved a lot)?
  2. Should Linux community rant about bigger problems such as Wayland related things not ready for current needs of normies?
184 comments

  • systemd is a godsend when you need service control while getting actual work done, at scale.

    there are legitimate things to criticize but in general the rants are incompetent preaching to the uninformed.

    • systemd is a godsend when you need service control while getting actual work done, at scale.

      there are legitimate things to criticize but in general the rants are incompetent preaching to the uninformed.

      Service control was systemd's main benefit and what it most excelled at. Having shell scripts for everything was a legitimate pain. It was all the other pieces of the ecosystem that it was wanting to subsume that got people upset (logging, cron, time, hostname, login, etc). Journald/binary logs was the main sticking point that I recall, though I figured it was a trade-off that was worth it, especially since you could have journald keep dumping to text anyway.

  • systemd isn't bad at all. People simply don't understand that it is not "just an init service".

  • I am fine with it and personally make heavy use of it. On my Arch install, I use systemd-boot, systemd-timesyncd, neworkd, resolved and unified kernel images with ukify.

    Roast me you systemd haters.

  • Ok, so I have a very unique background in systemd. I worked at Red Hat supporting it basically as the primary support and I've worked with the developers of systemd at Red Hat directly. I no longer work there.

    So first off, it's "systemd" all lower case. I don't care, but for some reason Lennart Pottering (creator) does.

    systemd was a MASSIVE change. And Red Hat did a TERRIBLE job relaying it. To the point where I'm still trying to get my company to understand that it can NOT be treated like the old init systems. You can NOT just drop an init script in place and walk away and hope it works. Because a LOT of times it doesn't. Due to forks, switch users, etc.

    systemd is NOT an init system. RHEL 5 and older had sysvinit as it's init systemd. RHEL 6 had UpStart as it's init system and looked exactly like sysvinit that no one even noticed. systemd again is NOT an init system. Init system is 1 part of systemd. systemd does a lot of cool things. It bundles applications together, it manages those applications and can restart them or kill children, it can do resource constraints, it separates out users from the system, and lots more.

    Because it is not an init system there is a LOT LOT LOT of bad recommendations out on the internet where someone has X problem and person suggests Y and IT WORKS! ... except it doesn't REALLY work as far as systemd is concerned and you'll hit other issues or your application takes longer to start or stop and people just blame systemd.

    It is systemd's fault that it has done an ATROCIOUS job of helping people adapt. It's a great example of RTFM. systemd's man pages are INCREDIBLE and extensive, but when you drop so much knowledge it becomes more difficult to find what you want/need. systemd.index and systemd.directives are your best bet.

    So systemd does a lot of amazing things that sysvinit never attempted to do. It's never attempted to explain anything it expects everyone just learn magically. it's INCREDIBLY complex, but once you understand it's basics you can more easily get an application running, but as soon as there's a problem it'll just break your brain.

    To give you an example, sshd's old init script is like 250 lines of bash. systemd's unit file comparative is like 12. Because systemd handles a LOT of what you manually had to handle before. BUT to get to that 12 you literally have to learn EVERYTHING new.

    There is no "is it good or bad" here really imo. It's a completely different fundamental design. Red Hat made it for themselves. Other distros picked it up. It can be argued that lots of folks followed Debian and Debian had a few Red Hat board members that were pushing it. Whether they pushed it of their own accord or because they were with Red Hat I don't have a clue.

    What I can say is at my current company they're suffering from a LOT of systemd issues and they don't even realize it. I've been working with Red Hat to try to get Insights to alert people to the failures and we're making progress.

    To see if you have issues just to start run the two following commands: 

     undefined
        ~~~
# systemctl list-units --failed
# systemd-cgls
~~~

    If you have any units that are failed, investigate those. If you don't need them, disable them. As for the systemd-cgls this shows HOW systemd is grouping things. ANY application that runs as a service (or daemon or application or runs in the background or however you wanna say it) should be under system.slice. ONLY humans logging into the system (meat bags NOT applications switching to users) should be in user.slice. A LOT of times what happens is an old init script is dropped in place, they start it, it has a switch user and systemd assumes it's a user and puts it into user.slice. systemd does NOT treat anything in user.slice the same as in system.slice and this WILL eventually cause problems.

    So again, is it good or bad? Eh. It does a lot of cool things, but they did a MASSIVE disservice to ALL of us by just expecting to relearn absolutely EVERYTHING.

    • sshd's init script under OpenRC is 87 lines, of which around half are blanks, comments, closing braces, and other boilerplate. Granted, that still makes the real code maybe three times the size of your systemd unit file, but the difference isn't as impressive as you're making out.

      95% of people shouldn't need to poke around in their init scripts or unit files anyway. If you actually need to do that, your use case is already somewhat unusual.

      • As an end user, unless you're running a server, then no you shouldn't have to mess with any of it.

        If you're running a server or a sysadmin you absolutely 100% should be paying attention. Almost every single vendor I've seen selling their applications only have initscripts. Which then cause issues. I've gone to the vendors and told them and they've said go to Red Hat. Well Red Hat doesn't support that vendor's init scripts.

        Not naming an application, but it was from a BIG BLUE company and they said their only instructions are to call their script from the user. But it won't remain running if you do that because systemd will close out the slice when the user logs out. SO it's obvious they haven't tried what they're suggesting.

        And I'm not attempting to state that systemd is impressive in any way. systemd basically took what had been building over 40 years of init scripting and threw it out the window and said our way is better. I don't think it is. I'm just saying, with a directive based unit file it'll be simpler to parse than a bash script.

  • Speaking as someone who uses OpenRC on all my machines . . . no, systemd is not necessarily slow, and personally I don't care about the speed of my init system anyway. Thing is, systemd also has nothing that makes it more useful to me than OpenRC, so I have no incentive to change. Plus, I dislike the philosophy behind it, the bloat, and the obnoxious behaviour the project showed when interacting with others in its early days. I'm a splitter, not a lumper, and systemd's attempts to absorb All The Things strike me as rather . . . Windows-like.

    So, in a technical sense I have no reason to believe that systemd is inferior to OpenRC + sysv, and it may be superior for some use cases which are not mine. I don't spend a lot of time ranting about it, and I see no point in trying to convince people not to use it if it fits their needs. But I still won't use it if I have another option.

    • I agree. SystemD is a great service daemon (or, sigh, unit daemon in the stupid parlance). I like unit file syntax and I like the ergonomics of systemctl. It's solid and I appreciate the feeling of consistency that systemd lends to the otherwise chaotic landscape of Linux distrobutions.

      It's for this reason that I'm willing to forgive SystemD overstepping the boundaries of services somewhat. System init/mounting? Sure, that's a blurry line after all. Logging? Okay -- it does make sense to provide a single reliable solution if the alternative is dealing with dozens of different implementations. Network resolution & session management? Fine, I'll begrudgingly accept that it's convenient to be able to treat logins/networking as psuedo-services for the sake of dependencies.

      If that's as far as the scope crept, SystemD and I would be cool, but the so-called "component" list just keeps on going. SystemD has no business being a boot manager, nor a credential manager, nor a user manager, nor a container manager, nor an NTP client. I understand why they can't deprecate most of this junk, but why can't they just at least make this cruft optional to install?

      • Systemd (PID1) is not your boot manager, network deamon, resolver, user manager or ntp service.

        Those are entirely independent deamons that happen to be developed under the systemd project umbrella but can be exchanged for equivalent components.
        Tkey are gully optional.

        In many cases, the systemd project's one is one of the best choices though, especially when used with other systemd-developed components.
        In some cases, there is no other viable choice because the systemd- is just better and nobody wants to deal with something worse.

  • We'd probably need to qualify this with "bad compared to what". I can't complain, as it does its job, and I've been able to tweak what I needed to. As I don't tinker with it every week, I keep a sticky note rolled up on my desktop, or I quickly use 'cheat systemd' to remember some key examples.

    I was getting really long start up time earlier this year (like 19 mins before the desktop was fully responding) and after trying everything else I tried ditching BTRFS and reverting my /home drive back to ext4. Turns out BTRFS start and checks was killing my boot times. Now, as fast as anything.

    The following have been my saviours though in identifying boot times: journalctl -b -p err systemd-analyze blame --user systemd-analyze blame

  • The Systemd init system and its consequences have been a disaster for the human race. It has greatly increased the life-expectancy of those of us who live in “just werks” distros, but it has destabilized GNU/Linux society, has made life unfulfilling, has subjected users to indignities, has led to widespread psychological suffering (in the BSD world to physical suffering as well) and has inflicted severe damage on the Unix world. The continued development of Systemd will worsen the situation. It will certainly subject human beings to greater indignities and inflict greater damage on the Unix world, it will probably lead to greater social disruption and psychological suffering, and it may lead to increased physical suffering even in “just werks” distros.

    The Systemd system may survive or it may break down. If it survives, it MAY eventually achieve a low level of physical and psychological suffering, but only after passing through a long and very painful period of adjustment and only at the cost of permanently reducing users and many other Unix processes to engineered products and mere cogs in the Systemd machine. Furthermore, if the system survives, the consequences will be inevitable: There is no way of reforming or modifying PID 1 so as to prevent it from depriving users of dignity and autonomy.

    If the system breaks down the consequences will still be very painful. But the bigger the system grows the more disastrous the results of its breakdown will be, so if it is to break down it had best break down sooner rather than later.

    We therefore advocate a revolution against the Systemd system. This revolution may or may not make use of violence; it may be sudden or it may be a relatively gradual process spanning a few decades. We can’t predict any of that. But we do outline in a very general way the measures that those who hate the Systemd system should take in order to prepare the way for a revolution against that form of society. This is not to be a POLITICAL revolution. Its object will be to overthrow not distros but the init-system basis of the present GNU/Linux ecosystem.

  • For someone coming from NeXTStep (BSD based), having worked with SCO, various BSD and mostly Linux for the last 20 years, the worst thing about systemd is documentation that's easily accessible/readable for people used to a traditional init system.

    "How do I get it to do special use case X" was a basically unanswerable question when it got dragged into the mainstream (for reasons I can very well understand - the reasons for the dragging, that is, the bad docs, not so much).

    Maybe that's improved in the mean time - I wouldn't know, I had to figure it out back then and now I know its lingo when searching and such.

  • It's not THAT bad. It was THAT BAD remembering who invented and pushed it. You know, all these psh-sh-sh-sh-audio memes. People just do not want to:

    1. Use software written by developer who didn't manage previous project to work properly.
    2. Change anything if it just works (c)(r)(tm).

    Currently systemd does its job well and right, despite on fact that systemd not so modular as you would expect. Event hardcore systemd haters now using it and happy. Including me :)

  • If we are talking about desktops and servers then yes and yes.

    However SystemD in an embedded system with tight process serialization needs, it's hell on earth.

  • SystemD is blamed for long boot times

    That is and always was nonsense. Systemd shortens boot times by starting things in parallel. That's one of its key features.

    There are some things to note about that:

    Systemd only starts services in parallel when it isn't told otherwise by Before and/or After settings in the service files. This makes it pretty easy to make systemd slow by misconfiguring it. You can use the systemd-analyze program to see which services held up your boot.

    Systemd has a very long default timeout (90 seconds) for starting or stopping a service. It's appropriate for the big, lumbering servers that systemd was probably designed for, but it might be wise to shorten the timeout on desktops, where a service taking more than 5 seconds to start is almost certainly broken. It's a setting in /etc/systemd/system.conf.

    Is the current SystemD rant derived from years ago (while they’ve improved a lot)?

    I'm an early adopter of systemd. I installed it on my Debian desktops pretty much as soon as it was available in Debian, and I later started moving servers to it as well. I had long been jealous of Windows NT's service manager, and systemd is exactly what I had hoped would come to Linux one day.

    Yes, the rant you're talking about is old, and yes, systemd is better now than it was then, but not in the sense of what the rant was complaining about. The rant was already patent nonsense when it was written, which has given me a very dim view of the anti-systemd crowd.

    Besides systemd proper, they also spent a lot of time ranting about the journal system, which redirects syslog entries into a set of binary log files. They complained that this would make logs impossible to read in emergencies. This isn't even close to being true—any emergency bootable Linux image worth its salt has a copy of journalctl on it—and the binary nature of systemd's logs has caused me serious problems on exactly zero occasions.

  • As service manager systemd nice, but look all services: 

     undefined
        
systemd + systemd/journal + systemd/Timers
systemd-boot
systemd-creds
systemd-cryptenroll
systemd-firstboot
systemd-home
systemd-logind
systemd-networkd
systemd-nspawn
systemd-resolved
systemd-stub
systemd-sysusers
systemd-timesyncd

    That's look as overkill. I use only systemd, journald, systemd-boot, systemd-networkd, systemd-resolved and systemd-timesyncd, but that a lot systemd. Feel like system make monolith.

    systemd-nspawn for example. Systems manager for containers. Seriously. Why than exists? I don't understand. Really, someone use that daemon?

    • I think that's a bad argument. If you go out of your way to install and configure all of these, then yes, they exist and you can do that - but that doesn't automatically mean they're bad.

      But in most operating systems they're not installed, not configured, and you'll never have to deal with any of that.

      I actually use systemd-boot because it's very easy to install and configure and systemd-resolved, but for a lot of those I haven't even heard about.

      And furthermore even if more of them (I think it's highly unlikely that any OS would use all of those services by default) were preinstalled, they'd only be an issue if they'd cause trouble. If your system is running systemd-whatever and it works well then what's the issue? The name itself?

      • As I wrote below, the problem is that this does not comply with the principle of K.I.S.S. One application should solve one task and can be replaced. Even now it is quite difficult to remove systemd-logind, for example. Because, although these are different services, they have long merged into a huge tangle.

        I actually use systemd-boot because it’s very easy to install and configure and systemd-resolved, but for a lot of those I haven’t even heard about.

        you can use EFISTUB If you don't have dual boot. This literally load kernel from UEFI. I don't know more simple way. https://wiki.archlinux.org/title/EFISTUB

    • How you would replace those in non-SystemD setup? Asking for learning purposes.

      • In fact, this is a difficult question.

        In Linux, it is usually customary to use the K.I.S.S. methodology, In any case, it was once customary to use it. This in some way meant that there were a huge number of applications performing exactly one task. For example, chron only started timers, ntpd only adjusted the time, grub only loaded the system and nothing else. It also allowed you to change the components at your discretion. With systemd this principle was somewhat lost, since one service with a huge number of its own daemons absorbs more and more functions. This is what causes concern. In some sense, if systemd at some point becomes even more monolithic, it will no longer be possible to change only part of its functionality. For example, I'm not sure if it's possible to disable journald and leave only rsyslog.

        On the other hand, the now-forgotten init.V fully adhered to the principle of K.I.S.S. since he was literally the initiator of a set of scripts that could contain anything. If you want, change the user at startup via exec, if you want via su. Isolate the application with any available program. It was as flexible as possible, but on the other hand, the entry threshold was quite high. The complexity of writing scripts for init.V was much higher than systemd.

        Therefore, there is no single answer. On the one hand, init.V have maximum modularity, on the other hand, systemd have ease of use.

      • or maybe I didn't understand the question. If you about that change daemons to non systemd, then:

        systemd-boot -> grub, lilo, efistub

        systemd-networkd -> some system scripts (different for different distributions), netplan, NetworkManager

        systemd-resolved -> dnsmasq, bind, set directly on 8.8.8.8

        systemd-timesyncd -> chrony, ntp

        journal -> rsyslog

        systemd -> init.V, openRC

    • AFAIK, nspawn is mostly a debugging tool for working with the init system without having to actually boot a live system/VM. At least that's all I've ever used it for.

      • It also a use case. =)

        The documentation for systemd-nspawn itself says:

        systemd-nspawn — Spawn a command or OS in a light-weight container

        The developers themselves position the daemon as a simple alternative to LXD containers.

    • Feel like system make monolith.

      you do know what the linux kernel is, right?
      Spoiler: It's a monolithic kernel

      In the end your distro packager decided to not split systemd into different packages, I believe only Gentoo does actually guide you to this
      so you actually barking on the wrong tree

      • you do know what the linux kernel is, right?

        I know that the core is monolithic.

        In the end your distro packager decided to not split systemd into different packages

        I installed these services myself, not all of them, of course, but those that I listed at the end. I know about the rest simply because I prefer to read the documentation for the services I work with. I'm not particularly happy with the systemd system as a whole. however, since there is no better alternative, the choice is small.

  • No. The people with a raging hate boner for systemd are just a vocal minority in lots of online Linux spaces.

    Most people either don't care or actively prefer it. Personally, I much prefer unit files to hacking away at init scripts or whatever the fuck Upstart was.

  • Yes. Yes it is. systemd isn't bad for boot times, but more for tying so many goddamn things to init, PID1, creating just about the best attack point one could ever ask for. Wayland not being ready can be solved by not using it for the time being. Just use X. Also, it's still called plymouth.

  • As a guy that's been installing Linux since you had to compile network drivers and adjust the init scripts to use them; SystemD rocks.

    1. Is the current SystemD rant derived from years ago (while they’ve improved a lot)?

    No it's almost always been derived from people's behinds.

    1. Should Linux community rant about bigger problems such as Wayland related things not ready for current needs of normies?

    Yes.

    Systemd is spectacular in many ways. Every modern OS has a process management system that can handle dependencies, schedule, manage restarts via policy and a lot more. Systemd is pretty sophisticated on that front. I've been able to get it to manage countless services in many environments with great success and few lines of code.

  • The traditional init systems suited me just fine, i saw no need to change them. If they were so bad, then they could've been fixed or replaced.

    The migration to systemd felt forced. Debian surprised everyone with the change. Also systemd's development is/was backed by corporate Red Hat, their lead developer wasn't exactly loved either and is now working for Microsoft. Of course Canonical's Ubuntu adopted it as well. Overall feels like Windows' svchost.exe, hence people accusing it of vendor lock-in.

    It's not just an init system, it's way waaay more. It's supposed to be modular, but good luck keeping only its PID1 in a distro that supports systemd. It breaks the "do one thing right" approach and, in practice, does take away choice which pisses me off.

    I had been using Debian since Woody, but that make me change to Gentoo on my desktop which, to me, took the best path: they default to OpenRC but you're free to use systemd if you want to. That's choice. For servers i now prefer Slackware and the laptop runs Devuan whenever i boot it up.

    To be fair systemd hasn't shown its ugly face in the Ubuntu VMs i'm forced to use at work.

    YMMV. If you're happy with it, fine. This, of course, is only my opinion.

  • Boot times aren't really an issue and not really relevant to good vs bad. You should be able to rice each one for speed on your particular use case if you really want to.

    Be wary of anything you get from RedHat. I use their stuff sometimes but ensure I can happily live without gnome, systemd, pipewire, wayland or whatever else they are generously gifting to us freeloaders.

184 comments