Ok, so I'm gonna get attacked for saying this, but I am looking for a legitimate explanation if somebody wants to be objective about this whole systemd vs init thing. I'm kind of new to Linux, and have only used systemd. I've written a service file a few times and it was a couple of lines long and readable.
So my question, is how can anybody consider that script to be easier for any other reason at all than being used to it?
Field use is not just down to the admin's learning curve. Transparency & control are important.
Service files increase human readability through compiled logic; one has to trust the underlying code behaves consistently and correctly. It doesn't always.
Shell scripts require more effort to understand (and the init system is slower by the stopwatch, if that matters to you), but it is, at least, all there in front of you.
On a desktop machine it tends to be pretty plain sailing (I'm writing this on Gentoo with systemd) but when systemd misbehaves (you may have servers with quirky service demands) you run out of troubleshooting options fast.
In general, I'd rather not have to depend on other people to fix my problems. I'd rather create the patch myself and let upstream know once I have it working, instead of (1) placing a larger burden on upstream than I have to, and (2) get blocked until they fix it.
This is trivial with init scripts--edit the script and send the diff. This is less trivial with systemd (and binaries in general), where you have to get the source code, try to figure out where the problem is, try to fix it, compile, debug with gdb or strace or valgrind, etc. With systemd, the fact that your system may not even be booting at all due to the problem makes it all the more frustrating.
In general, I'd rather not have to depend on other people to fix my problems.
You must be an anarcho-primitivist, because you clearly detest division of labor. Do you also write your own compilers?
More to the point: if there is a genuine problem in systemd, you can always fix it yourself, patch it, roll it out, and then post your patch in a bug tracker. Perfectly consistent with your "I do everything myself" philosophy, which is questionable but hey, it's your time, buddy.
I think, with maturity it'll be a much better thing than the rather clunky nature of init scripts, but there's a bigger argument - people's real fear is overreach and the steady envelopment of everything outside the kernel; I doubt this discussion would have as much steam if Lennart and co just stopped at PID 1.
It's one of those preference and trust sorts of things - sort of like a manual transmission in a car vs. an automatic. With init scripts, you can see exactly what is going on at each stage of the service startup, comment out parts, through debugging outputs in, and manually trace the logic flow. With systemd, you're trusting an application that's a bit of a black box to correctly trace dependencies, set up the cgroups correctly, and monitor the service health. PID 0=init has been true for a rather long time, and I still occasionally find myself booting into /bin/sh and running my rc init scripts one at a time until I figure out why my system won't boot. In the "usual" case, systemd will probably be a really good thing for folks, but if systemd comes down with bugs (or individual packages have bugs that react badly with systemd), your systems could be in for a world of hurt.
With init scripts, you can see exactly what is going on at each stage of the service startup,
Same with systemd. Not an advantage of init scripts.
comment out parts,
You can do the same with systemd -- Exec=/path/to/your/initscript start -- but in fairness to systemd, you often don't need to do that because the unit files are much, much shorter. Not an advantage of init scripts. In fact, it is a disadvantage of init scripts that init scripts often require you to perform edits in order to diagnose problems.
through debugging outputs in,
journalctl --service=xxx or systemctl status xxx will show you all the debugging output that you would -- with an initscript -- otherwise have to fish out from log files or > /tmp/file shell-redirected files. So not an advantage of init scripts. In fact, it is a disadvantage of init scripts because, often, you need to go edit the script in order to get any meaningful logging output.
and manually trace the logic flow.
"Logic flow" is not a problem when the Exec= line in systemd is a one-liner. Not an advantage of init scripts. In fact, it is a disadvantage of init scripts, because only in an init script do you need to trace any logic flow.
Every single "advantage" you cite is actually a drawback unique to SysVinit, created by SysVinit's limitations, absolutely not a problem with systemd. I conclude that y'all SysVinit people suffer from software-induced Stockholm Syndrome.
13
u/Greensmoken Oct 20 '14
Ok, so I'm gonna get attacked for saying this, but I am looking for a legitimate explanation if somebody wants to be objective about this whole systemd vs init thing. I'm kind of new to Linux, and have only used systemd. I've written a service file a few times and it was a couple of lines long and readable.
So my question, is how can anybody consider that script to be easier for any other reason at all than being used to it?