It's obvious that the author of this article has never actually used systemd. For example, he complains that the startup sequence is "written in C," so the only way to change it is to recompile systemd itself. This is utter nonsense; systemd uses tiny config files called units to configure everything, so there is no reason to recompile. It's hard to take these complaints seriously when the author clearly hasn't used the thing he's complaining about, or ever read the man page.
A few months ago, I actually installed systemd on my laptop to see what the fuss was about. It was one of the best things I've ever done. Before systemd, system bootup was controlled by a bunch of shell scripts that made no sense to me; if I wanted to add a new daemon, my only hope was to copy-paste a similar-looking script from /etc/rc.d. Now, my bootup is controlled by a bunch of trivial config files like this:
So, this idea that systemd somehow makes the system more complicated is utterly false; systemd is a great simplification from an admin's point of view. Sure, the systemd daemon might be a bit larger than the classic init daemon, but RAM is cheap these days and admin's time is not. I think this is a good tradeoff.
Systemd has these stupid config files. And by stupid, I mean that literally. They replaced init files (with arguably too much logic) with these simplistic config files that have no logic available.
What ends up happening is you replace init files with nothing, and you have to push out any logic to an intermediate script or binary which just adds indirection.
In 20 years of managing Linux systems, I can probably count on one hand the time I saw an init script that was written properly unless it was provided by the distro maintainers (and often not then either). That is, it included all the expected options for the service, it correctly handled pid files for daemons that for whatever reason doesn't do it themselves, it handled reload's gracefully, and so on.
Good riddance to init files.
If these people want to keep people from using systemd, they need to come up with a better alternative.
Hah! Yeah I've definitely been bitten by this but, I've also been bitten in general by systems that are nonsensical and impossible to understand. The difference in the rc case is that I have a chance at reimplementing it in a sane way, probably given a few hours. I have no hope of understanding systemd in months, let alone replacing it or modifying it in hours.
There's a real genius in implementing the init system as a bunch of scripts. I sympathize with devs who have to maintain... 4 (?) different scripts for different systems, and boot times are definitely better. But the major issues were "hey I'd like to maintain fewer scripts, I wish my desktop booted faster, and having some way to list dependencies in my startup script would be nice", and I just don't think that "OK, we can fix that by completely overhauling system logging, daemons, configuration and management in 100,000s LOC of completely new, non-portable C code" was a reasonable response.
The goal of systemd as an *init system* is not the same thing as the goal of some of the systemd umbrella projects, and they shouldn't be conflated. systemd as an init system is leaps and bounds ahead of sysvinit, openrc, and upstart for distro maintainers, large scale sysadmins, etc. No more need for supervisord, random scripts to flag off and on was part of VPN connection, convoluted "meta" scripts which carefully restart 5 different services in the same order and a huge mess of shell.
That said, no, Lennart did not/does not do things that way on his personal laptop. His position is that users shouldn't need to know how to configure dnsmasq to have a local caching DNS server, that 99% of the options for dhcpcd aren't used by 99% of users (who are perfectly happy to simply get an address in a fraction of the time), that most users don't need to know how to configure /etc/sysconfig/network-scripts/ifcfg-* or /etc/network/interfaces/* for their use case.
If you do, you can disable those things. You can think this is a good opinion or a bad opinion, but at least he's pushing towards some kind of solution which isn't "RTFM". If you think his ideas are bad, propose new ones. Start a project which does it better. "Just don't change anything" is not a meaningful or productive way to design software or operating systems.
> Prior init's were actually quite easy to replace and alternatives were often used, but these days most software assumes systemd and this situation gets worse every year.
Not really. Sysvinit scripts are... scripts full of sysvinitisms (double forking and PID files, anyone?). Idiomatic systemd daemons are, comparatively speaking, very straightforward. Of course, there are a lot of nice-to-have features, but to get a running system, you should largely be able to get away with parsing Wants=, After=, and ExecStart=.
Thank you for putting this argument across so succinctly and with such good research behind it. Everytime I hear the arguments in favor of systemd, I wonder when these people actually come down from their ivory towers to do some real life work, where the rubber meets the road.
The argument of "lines of code" in a startup script is such a stupid strawman, it defies belief. I design and build large scale production system, and have exactly zero interest in the size (or complexity) of a startup script. I am interested in being secure in the knowledge that a control script handles all possible cases, including edge cases, that might present themselves during the forseeable lifecycle of the service/application in a predictable and understandable manner. If it takes a bit more time and work to understand these scripts, so be it - what are a few extra hours (which, incidentally, force you into a better understanding of the thing your working on - always a good thing) when seen across the timeline fo the service lifecycle?
systemd does a few cool things, and many blindingly retarded things. It is probably really nice to have on your laptop, what with the fast boot times and all, but many of the things touted as "advantages" really do not hold up for server work. What do I care if my boot time is a few seconds less on a server? rebooting a prod server is usually a scheduled event, with (depending on the context) can call for anywhere between a 30 to 120 minute maintenance window.
The systemd people should be made to work building and maintaining a real-life backend environment for a while.
He thinks unified config files are simpler than ad-hoc shell scripts for init systems.
That's a gross misrepresentation of the problem. Shell-based rc does not have to be "ad-hoc" if there is a sane process management framework in place. In such cases, the scripts can be extremely terse. [1] [2] In essence, the scripts become mere "callbacks" and have their primary purpose to provide the start command line, optionally with some form of chain loading to compose execution state. One can go further and write a small, special-purpose LL(1) command language for chain loading of programs, e.g. execline. The unit file format, conversely, cannot be composed, the options must be treated as static entries, and implicit state is carried, sometimes making service writers resort to horrifically subverting the systemd model just to escape. [3]
My personal experience with writing sysvinit scripts agrees pretty well with s_tec's view. Those shell scripts would easily have been replaced by trivial .ini files and contained several bugs before I managed to figure out how to use start-stop-daemon correctly and fix some typos.
I have not used systemd myself but it seems trivial in comparison to my experience writing sysvinit scripts.
I know you didn't get the chance to read this, but it specifically says:
Disclaimer: We are not sysvinit purists by any means. We do recognize the need for a new init system in the 21st century, but systemd is not it.
And I don't think that's an invalid point. I totally agree that a better init system is desirable, but I've also personally really struggled to understand why systemd is a good approach – it does seem, from someone who's not that close to the issue, that it's an extremely complex and monolithic approach to the problem.
I'm just going to assume you're not a troll, because your arguments are widespread, regardless.
Systemd is far more than an init system, it has 69 binaries !
It's actually far more than 69 binaries by now. That's a long outdated number. Nor did I ever imply systemd is just an init system. Where did you get that?
sysV init has no notion of plugin nor module system, but has a notion of script file
Where did I mention sysvinit? I wasn't talking about sysvinit. finit and initng are examples of plugin-based init systems.
Like systemd the init system
It would be very odd if an init system didn't have some way of configuring a service, don't you think? I don't see how this is meaningful at all - it's an absolute fundamental given.
But you can also plug yourself via the dbus api, which is far more powerful
Which, as I stated in a previous post, is nowhere near sufficient for the level of extensibility that I was referring to, such as that of Emacs. The D-Bus API is useful for writing layers of abstraction and remotely controlling and querying the daemon(s) in a more convenient way.
If that's what you are suggesting to do, you are not supposed to directly modify and recompile your init system for causal changes. If you want to change its behavior, use command line flags or configuration file.
And why the hell not?
There is no "not supposed to" here, it's only a) improperly designed architecture and b) lack of imagination that makes it so.
Yes, in systemd's case, such a thing is not meant to be done. The reason is because the init daemon is coupled with the process management and supervision framework, among other components. As other init designs have shown, a dynamic plugin architecture is practical and useful provided components are more loosely coupled.
I'm also curious as to why you mention "recompile". The whole point of plugins is that you don't need to do that.
It's really funny that systemd proponents make such bland arguments deeply rooted in tradition. The same ones they decry a lot of opponents for making.
I genuinely don't see what's so complex about a service unit file. It's a simple INI file that has multiple sections that describes the service, tells what command to run and specifies any dependencies. It's literally the same thing that init scripts do except in a much more concise and efficient manner. And as I said before, there's a ton of systemd service unit files on any Linux system that you can take a look at and use as inspiration for your own services. Taking a little time to learn the ways of systemd is not a huge burdensome task like you're making it seem to be. I don't see why you think everyone should conflate systemd with complexity.
And about the voluminous documentation, well man pages are supposed to be comprehensive and cover every single aspect of the tools being described. They're not there to just be an intro to systemd for new users and administrators. If you want something like that, look no further that the "systemd for Administrators" series of articles written by the systemd author himself. https://github.com/shibumi/systemd-for-administrators/blob/m....
> All features of this new process invocation system could be implemented without making a "new init system."
Er, no. A major feature of systemd is that it is declarative. You have hooks for running custom commands, but a unit file is declarative and easy to parse.
If you want to acquire more intelligence about an init script, you have to resort to disgusting hacks like parsing comments in order to get a dependency system working. And socket-based activation? Sysvinit is a dead end. It's the counter to "keep it simple, stupid": when you fail to capture enough information in your "simple" model, you are going to end up with more issues than if you had created a slightly more complex system.
This, and it seems like it needs repeating every time somebody brings up systemd.
The SysV init scripts weren't good, they were crufty and slow, and messy when you wanted to customize something, and -- this doesn't get said enough -- used no Linux-specific features at all. Systemd was an upgrade that was sorely needed, and brought features to the init system that just didn't exist before.
They'd get much further if they actually came up with a better alternative.
Even if all of there points were objectively true, it doesn't matter when sticking with the old init is so much worse in many ways.
People aren't picking systemd because it's perfect, but because both the mess of init scripts it is replacing, and alternatives like upstart,is seen as worse/too lacking.
EDIT: Btw. this just got me to install systemd on one of our dev/test Debian boxes at work, to start testing it.
A few months ago, I actually installed systemd on my laptop to see what the fuss was about. It was one of the best things I've ever done. Before systemd, system bootup was controlled by a bunch of shell scripts that made no sense to me; if I wanted to add a new daemon, my only hope was to copy-paste a similar-looking script from /etc/rc.d. Now, my bootup is controlled by a bunch of trivial config files like this:
So, this idea that systemd somehow makes the system more complicated is utterly false; systemd is a great simplification from an admin's point of view. Sure, the systemd daemon might be a bit larger than the classic init daemon, but RAM is cheap these days and admin's time is not. I think this is a good tradeoff.reply