I see a lot of arguments both for and against systemd.
The most common against is the whole PID 0 thing. I agree that’s not ideal.
But I’ve learnt so much more about being a sysadmin since switching to systemd Linux. It’s definitely easier and more convenient.
What do you think?
Well, since most distros seem to run it, it could end up being a bad thing. Say you have one bug or issue, it can spready to several different distros and cause issues with updates. It is fairly complex and there are a lot of eyes on it but the risk is still there.
I had to google, I never knew that hate existed. But sure enough a lot of people hate it.
I use systemd and I have no issues with it.
I did find an interesting post where people debate back and forth.
It’s worth a read.
Same here. People seem to have a lot of gripes with it. I guess this comes with the territory. I have seen plenty of debates and arguments happen online over different topics surrounding Linux. I think it just comes down to personal preference. It is always worth trying for yourself if you are not sure (based on what people online are saying).
This was quite an interesting question, especially with the post @Ben linked. As far as I can recall, I’ve had only positive experiences with systemd (but my experience with systemd in particular is not broad at all). The history and somewhat wide-reaching context involving systemd’s adoption (or forced compatibility for some) in UNIX-based or related OS distributions is definitely more in-depth than I expected. Nonetheless, a great bit of information learned today!
@glitch’s point is a good reminder to the importance of OS and software patch management, as the maintainers for system software, firmware, OS distributions, etc. should be assumed responsible for staying on top of security issues affecting their products/solutions.
People have different preferences.
In the abstract, you can think of it this way. One is picking on every pixel. The other just wants the program to work. The other installs Ubuntu and doesn’t know what systemd is. They can all argue, but the choice is theirs.
Thanks for all your replies and feedback on my question.
I think you all made clear and fair observations of it. Some don’t understand it, some worry, and others are just not bothered. This is probably the only place I have asked where people didn’t get into an argument over it and I appreciate that!
Old topic but I think I can help sort it out -
systemd is a necessary evil for personal computers, especially portable computers. There are a lot of things that have to go right, and change on the fly, that you really do need more than just a basic init system. systemd is following Apple’s launchd path and there’s a good reason Apple had to come up with launchd for their os.
However, for servers, VMs or containers I think it is mostly overkill, unless you require specific systemd features like cgroups and such. Process supervision the old school way is much more simple and easier to understand and just works (and debug when it doesn’t 
. If you want a good example and see for yourself, install Void Linux in a vm and go through their excellent handbook https://docs.voidlinux.org
There are oci/docker images that bundle alpine with runit or s6 suite, which is probably the best way to run stable services that don’t directly interact with each other.
In the end after thinking about it for years, I don’t think it matters - i decided this after I realized I don’t care about launchd on Mac OS, why should I care about systemd on Linux? It’s systems level software and is doing a basic job you usually don’t need to be concerned with. Get out of the lower levels and focus on something important.
My 0.02
You raise some valid points @xenyz
I really like that Void is an independently-developed distro, but fresh. I’ve yet to try it but writing a article about independent distros so will give it a spin. Apart from Void, have you also used Gentoo, Arch and Slackware?
Everything is a trade off. Systemd offers that simplicity of management with it’s unified configuration. It is generally more robust and stable when you compare it side by side against older init systems. However, PID 1 always raises eyebrows with the issue of single point of failure. I also find it not quite easy to master as a beginner.
There are reasons why many hate systemd.
It slowly engulfs many of the core userspace components, and replaces the previous counterparts.
The init system running at PID1 is really great when it comes to services.
Handling sockets is really good, but not in PID1.
It can be excused, as it works fine in practice.
But services are encouraged to be started in parallel with their dependencies.
It isn’t a good idea despite working apparently well… It’s like not following safety rules in traffic just because you haven’t experienced any accident yet…
AND it slowly “embraces” other software, then “extends” them, and then “extinguishes” them.
Example: It embraced secure booting and secureboot key management by supporting all required tools in kernel-install as well as ukify [systemd’s UKI builder]. It slowly “extended” them with more integrations and features. Then it extinguished them with systemd-sbsign, a tool meant to sign the UKI executables.
systemd-journald as well as socket activation, although a bit more radical, started out as a minimal bridge for the syslog socket, to record even those logs which were generated in the absence of syslog.
This way, it slowly starts “natively supporting” many features and subsystems, adds code within it to support more, and finally replaces the said software.
It has incorporated udevd, logind, has developed a network daemon and a resolver daemon, a daemon for the hostname [and hardware model], a daemon for managing locales, a daemon for managing [only managing] time and date settings. [The latter 3 are tolerable as they run only as needed].
It re-implements cryptsetup for internal ordering purposes.
It re-implements cron [you need 2 unit files 6+ lines each for what crontab would do in a single line]. [Although now systemd-cron is there…]
It has .swap .device .mount units which many find too much of wasted work… it just wraps around the commands!
It, yes, has done a lot of good to linux, but it also has done quite a little bad.
You can’t touch cgroups outside systemd.
66, s6-rc, openrc, dinit, shepherd, /etc/rc plain init, and many other inits do init very well… they don’t require the software to include init-specific code in them.
But systemd does… for readiness-notifcation, for socket activation, for many other things.
My personal gripe with it, despite using it, is that it doesn’t support musl, and the developer is too arrogant to include it. He is too stubborn and avoids constructive criticism. Also another gripe is that it doesn’t consider other init systems, takes active steps to push out others…
If you think “It implements timer activation” “s6/66 doesn’t have socket activation” “musl doesn’t support extensible NSS etc…”, please reply back to me. [A crontab entry to start a service, s6-fdholder, nsss (temporarily musl-nscd) respectively for those example questions…]
Welcome to the forums. Please tell us a bit about yourself here:
https://linuxcommunity.io/t/introduce-yourself-here/7/268
Thanks for joining the discusson.