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.
Looks to me like all Systemd does it move the logic from the init file itself and into a binary blob inside init.
And that blob is going to be harder to debug, never mind fix, on a production system. While your manager is breathing down your neck about getting it back up ASAP.
This. I would have been happy with anything that turned initscripts, which are often hundreds of lines, including tons of decisions and variables, into a simple declarative conifguration file. systemd seems to do OK at that, though I am vaguely uncomfortable with how tightly coupled things are in a systemd system.
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.
I use systemd to manage the (sort-of) microservices for some web app projects I've done. To me, the unit files are simple and even beautiful compared to the big pain that init scripts used to be.
Those old init scripts weren't simple - to do anything useful you had to copy and paste a whole heap of sh boilerplate...
If there's a systemd unit, the init script is redundant, confusing, and possibly dangerous. It should not exist in the first place, perhaps except as a thin wrapper around the corresponding systemd command.
I've had way more headache with badly written and plain faulty init scripts than with systemd, including systemd-networkd, systemd-timesyncd, systemd-resolved and systemd-nspawn, which I used to replace a lot of LXC, LXD and openvz setups.
Those scripts were different per distribution. Sometimes shared, but then had to be copied basically manually from one distribution to the other. With systemd it's just a configuration file shipped by upstream. Any fixes automatically get reused by all distributions.
The init scripts differed way too much across distributions. This including pointless differences in where various files are located. All of that has become way more standard, thankfully.
I did have various issues with a few init scripts of my distribution. It didn't happen often, but nowadays you usually can do with a config file, way easier.
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.
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.
The issue isn't that systemd makes init configurations unportable, it's that it makes programs unportable by tying them to systemd. What do we do 5 years down the line when we realise systemd was a bad idea and want to replace it with something else?
Am I the only person who prefers systemd? Maybe because it's the only init system I've managed to get my head around. Other init systems seem so complicated. A config file vs a bash script is far easier and they all seem to require forking.
I only use Linux for servers so I may be unaware of a sane init system that works like systemd but isn't systemd. Until something like that appears, I'll stick to systemd.
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.
reply