What do you dislike about systemd? Do you disagree with the ideas behind it, or is your discontentment more about the specific implementation of those ideas? Can you give examples?
- It's effectively a black box that nobody but the systemd team really understands; and the response by said team to problems with systemd too often defaults to "you're doing it wrong"
- Systemd is not just an init system, it's a message bus, authentication system, logging system, container management system, xinitd system, and any other number of highly coupled systems.
- Service startup order can still be non-deterministic and fairly slow; hard init problems have been made harder, while easy init problems "only" remain easy.
- Unit files can be stored in a minimum of four separate locations on disk, and this can be increased dynamically.
- Failures are opaque, and the failure of systemd triggers the failure of the entire system.
The original idea that drove systemd's creation is still fairly sound: create a simple, deterministic, and parallel init system which is better than initv. The implementation doesn't live up to those goals, and instead of iterating against that goal, the team's focus has shifted to take over all aspects of the Linux runtime which isn't managed by the kernel.
> - It's effectively a black box that nobody but the systemd team really understands; and the response by said team to problems with systemd too often defaults to "you're doing it wrong"
I'm seeing this attitude a lot. Just last week, at our Linux User Group meeting, someone brought in a notebook with Debian 9, which didn't boot up correctly because drives were not detected.
The issue turned out to be really simple (udevd is started after `udevadm trigger`, so device files do not get created), and I advised them to file a bugreport with Debian about this. But it still took over an hour to diagnose because everyone around me was bickering how impossible it was to diagnose anything with systemd, whereas I just looked at `systemd-analyze plot`, `journalctl` and poked around a bit.
So, not something that I would call opaque. It's just that they're not used to it. I never really learned inits before systemd (I knew how to enable and disable services on $distro, but that was about it).
So, the "impossible it was to diagnose anything with systemd" comes about because "systemd-analyze plot" and "journalctl" have no meaning prior to systemd. It's a whole new toolset which needs to be learned.
It doesn't follow any existing patterns, which makes it harder to learn if you're already familiar with troubleshooting init prior to systemd (troubleshooting which would have started with a quick trip to /var/log/dmesg and stopped with /var/log/syslog).
So yes, it can absolutely be learned. But existing administrators have to abandon most of their existing toolkit to do so.
That all said, that's not what I mean by opaque. By opaque, I'm referring to how many (few?) people truly grok what's going on inside of systemd. As an arbitrary point of measure - systemd (and only systemd) consists of over 500,000 lines of C code. It takes a lot of dedication and time to understand what is going on in that much C code. There are, by GitHub stats, less than 10 people who have contributed (combined additions and deletions in commits) to even 1% of the codebase, and only 4 who have touched more than 50%.
In comparison, sysvinit consists of about 9,300 lines, and upstart 115,000.
Also, where before one could mark1 eyeball what the bootup was trying to do, and reason fixes from that, now one have to rely on an analyzer to tell what the sequence will be. And if said analyzer can't be used, what then?
And similarly the journal format is something that can only be read with the journalctl tool. plain ascii you can throw just about anything at.
I have to second this. I am a long-time Linux user, having run Debian since the late 90s and Slackware since 1993 but systemd put me over the edge. Things that worked and were easy to figure out in the previous init system just stopped working under systemd. It is a brutally complicated init that didn't add anything to my experience and pushed me out of Debian and into FreeBSD where things still have sane defaults. I like to get my work done instead of messing around with an init system that refuses to let me do even the most basic things.
Not all new things are great and I think Debian made a mistake not supporting a traditional init system alongside systemd or at least until the kinks could be worked out.
Thank you for your response falcolas. Addressing your points:
> "- It's effectively a black box that nobody but the systemd team really understands; and the response by said team to problems with systemd too often defaults to "you're doing it wrong""
Is this because the data being passed around is represented in binary form rather than text form (e.g. binary logs rather than text-based logs)?
> "- Systemd is not just an init system, it's a message bus, authentication system, logging system, container management system, xinitd system, and any other number of highly coupled systems."
Sure, but this doesn't strike me as neccessarily bad. I appreciate the Unix philosophy is based around having a series of tools that serve a single purpose that can be chained together in different ways, but it's still a necessity to have common interfaces over which this chaining takes place. Is this again related to the binary vs. text issue?
> "- Service startup order can still be non-deterministic and fairly slow; hard init problems have been made harder, while easy init problems "only" remain easy."
The non-determinism and speed of start up both strike me as major issues, thank you for mentioning them. Does anyone know if there are there plans to tackle these issues?
> "- Unit files can be stored in a minimum of four separate locations on disk, and this can be increased dynamically."
Again, this also seems like a reasonable complaint. Is this issue due to the intrinsic design of systemd or is this solely a flaw in the implementation?
> "- Failures are opaque, and the failure of systemd triggers the failure of the entire system."
Are there no fallbacks in place should a systemd component fail? I see no reason why this couldn't be implemented.
> "and instead of iterating against that goal, the team's focus has shifted to take over all aspects of the Linux runtime which isn't managed by the kernel."
I don't disagree with that assessment, but there must be reasons why systemd is proving popular amongst distro maintainers. Why would you suggest that is? What advantages do you gain from having a unified layer that provides the services that systemd provides?
> Is this because the data being passed around is represented in binary form rather than text form
None of my complaints relate to binary vs. text. Both have their strengths and weaknesses, and while binary data requires new set of tooling, I intentionally did not mention it because of how contentious it is to even bring up.
> Sure, but this doesn't strike me as neccessarily bad.
It's just not necessary. This all worked before. Not always perfectly, and sometimes even poorly... but it worked. And importantly, it worked without requiring the authentication system, message bus (tied into the kernel), custom logging, and init all to be tied together.
> What advantages do you gain from having a unified layer that provides the services that systemd provides?
Personally? None - no advantages. Consider where I'm coming from - I've run Linux on the desktop and server for years (perhaps even before systemd was a glimmer in Pottering's eye). I've written software which ran on startup (including the sysvinit scripts), done init troubleshooting... and it all just worked.
Without reasonable gains in speed, and without resolving the determinism problem, and given a world in which supervisord, daemontools, and LXC exist... systemd just doesn't bring anything to the table that I've been asking for. Instead, it's brought a whole new toolset I have to now learn, and a ton more complexity and opacity.
beefhash's explicitly stated rationale was reuniting the community. By attempting to derail this into yet another massive thread about the merits/demerits of systemd, rather than a discussion of the desired future and already present capabilities of the Debian installer, and putting words into beefhash´s mouth that xe did not say as you have done here, you are instigating exactly the opposite.
In order to 'reunite the community' you need to understand what that will take. Every init system that is supported adds an additional support burden onto the developers and maintainers that work on Debian. In order to minimise that work, it's important to understand the issues with the status quo.
At one end of the spectrum, perhaps a few tweaks to systemd would be enough to satisfy most who had issues with it in the past. On the opposite end of the spectrum you have the distro needing to support 5+ init systems if there's little consensus about what a strong alternative to systemd would look like.
The questions I asked previously are useful in understanding how much work would be required to 'reunite the community'. Feel free to answer them if you think this is a worthwhile line of inquiry.
