I don't think you're wrong. I imagine all these people saying systemd is so awful are just worried that their hard-earned sysvinit knowledge will become obsolete and that new users won't have to go through silly bash scripts (that are totally secure of course - no chance of security vulnerabilities in something as ancient and wtf-free as bash). Instead they'll have something sane like this:
I think this Debian fork talk is a bunch of nonsense, but so is your comment. It's the classic "systemd or sysvinit" false dichotomy, as evidently a ton of Linux users have never stepped out of their cage to ever look at anything else.
Besides all the sysvinit alternatives (like depinit) that have popped up throughout the years, fixed most of its deficiencies and were promptly ignored, even having a shell-based boot doesn't mean you need to resort to the antipatterns that Linux distros have been doing - look at what the BSDs do with /etc/rc.subr and rcorder(8). Though, to some extent, this can be blamed on sysvinit's flawed abstractions.
If anything, making a "systemd or sysvinit" dichotomy only tells me you're unknowledgeable.
You're totally right about the false dichotomy, but I don't see why you think other init system were ignored.
Debian used a really open process to decide the new default init system where every developer could propose any init system provided that someone offered to maintain it.
Since SysVinit, systemd and Upstart where the only ones with a credible maintainership (OpenRC didn't work on Debian until a few week after the discussion started) the discussion was centered on those three.
So it's not like other init system were ignored, it's just that noone bothered to do the actual work to make them suitable replacements.
My hypothesis is that systemd was the first to provide enough benefits to motivate people to implement the switch in Debian.
From a distribution maintainer the fact that systemd tackles many loosely related problems is an actual benefit, since now said maintainer just need to coordinate with an upstream project instead of having to maintain dozens of special snowflake systems (eg. to set the hostname). This is what most systemd critics fail to accept.
Oh, and the shell is nice but it's one of the worst languages to implement anything non-trivial, http://www.dwheeler.com/essays/filenames-in-shell.html is enough for me welcome the idea of getting rid of it in the boot process. :)
Doesn't it do logging? And cron? And login/console? And configure network interfaces? And a bunch of other stuff...
... systemv sucks enough that I'm in the middle of re-working our firmware at work to use systemd instead (I do like socket activation and supervisor stuff), but of all the systemd features one could like, "do one thing and do it well" isn't one of them.
only the journal is a required additional feature of systemd, and you can set it up to not store anything and just forward to your syslog/rsyslog/...
you don't need to use systemd-networkd, it's a separate program - but it's better than debians /etc/network/intefaces adn RH /etc/sysconfig/network-scripts/if* - so I do welcome the consolidation it'll bring to distros.
you can still run normal cron
you don't need to run the kms console daemon either
The idea is that rcNG makes things simple, but it doesn't stand on your way if you want something more complex or in this case you want to make it harder to use than it needs to be.
Config test is a human operation; you manually do it after you've edited the configuration, and if you've forgotten to do it then the next start will crash. It makes no sense to automate configtest.
Sure it does! It's a belt-and-suspenders approach that ensures that human error won't cause your system services to become unavailable. Why use a computer unless it automates tedious tasks for you and remembers to do things that you might forget?
The Gentoo OpenRC BIND 9 init script runs named-checkconf every time you try to start or stop the BIND service or reload its configuration files.
This automatic check has saved me a bunch of time and mental overhead over the years. The auto-check has also prevented some downtime when I -inevitably- fat-fingered something in a config file.
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.
How does systemd handle situations where you need to check for the existence of directories and check their permissions, etc, before starting the service? You'd have to script it... and it would end up looking like a sysvinit script anyway.
You can add ConditionPathExists= or ConditionPathIsDirectory= to a Unit to check if one or more directories exist. You can also substitute the userid into commands with %U, so you could have it always chown before running the command, as you can have multiple ExecStart= directives.
At this point I don't really want to touch the systemd argument with a barge pole anymore, but I think it's worth saying that I'm a lot more comfortable with the sysvinit script.
After a lot of years of maintaining and editing and writing configuration files for more Linux daemons and applications than I can remember, my least favorite are the ones like the top example, that have a pile of predicates and values. They require careful reading of documentation to look for any traps and gotchas (the documentation always has a fine print section buried deep within it somewhere that says, "oh, by the way, you can't foo with a bar setting because that will cause a baz to foom"). You have to either memorize a bunch of variables specific to a single application, for a ton of applications, or you have to spend time referencing documentation (and re-reading it for those gotchas) every time you open the config file. There's also the nuisance of new predicates in later versions, hidden and undocumented predicates, and on and on.
It's just a pain in the ass. Really, as much as I love Postfix otherwise, it is the poster child for why this approach sucks monkey. Here's the documentation for Postfix: http://www.postfix.org/documentation.html ... let me know when you've read and understood all of it. :-)
But the sysvinit file on the other hand is easy. It looks uglier, but only to people that aren't accustomed to shell scripts. I can take one look at it and know what most of it does, because all other shell scripts do similar things.
And here's the best part! If the shell script seems to be broken for some reason, I can debug it! I can stuff some stdout or stderr in there; I can call my own binaries or reference other shell scripts; I can do programmer-y things to it!
The default response here is usually, "well, we'll just keep the configuration file simple then." But that never happens. I would bet a donut that, years and years ago, some Postfix developer said, "the sendmail configuration system sucks, we'll do our own, and we'll just make sure it stays simple."
But software never gets simpler. It's a steadfast law, a more universal rule of reality than the arrow of time. Software only moves in one direction, and that's towards more complexity. The safe bet is that ten years from now, those systemd configuration predicates will have exploded 10-fold, with lots of hairy edge cases and gotchas and hidden or poorly documented interactions, because that's what always happens. A shell script on the other hand will still be editable; the Apache sysvinit script you posted doesn't do anything that a shell script couldn't do 15 years ago.
I'm really beginning to think this whole systemd thing is actually a culture war between two different generations of sysadmins. The older, bearded generation wants to stay with the thing that has always worked out for them in the end, and the younger, nicer-smelling generation wants to do something new because they haven't made enough mistakes yet.
The system script posted is actually a fairly bad example because that one just use apache to manage the process. Where systemd shines is where we don't need specific purpose binaries to manage each service.
[Unit]
Description=A network traffic probe similar to the UNIX top command
Requires=network.target
ConditionPathExists=/var/lib/ntop/ntop_pw.db
After=syslog.target network.target
[Service]
Environment=LANG=C
ExecStart=/usr/bin/ntop -i eth0 -w 3000
Type=simple
StandardError=syslog
[Install]
WantedBy=multi-user.target
Note the lack of pid files of stop commands etc...
> And here's the best part! If the shell script seems to be broken for some reason, I can debug it! I can stuff some stdout or stderr in there; I can call my own binaries or reference other shell scripts; I can do programmer-y things to it!
systemd captures stdout/stderr and the exit code you rarely need to run it outside of systemd. Most of the time the ExecStart command would do the trick.
> I'm really beginning to think this whole systemd thing is actually a culture war between two different generations of sysadmins. The older, bearded generation wants to stay with the thing that has always worked out for them in the end, and the younger, nicer-smelling generation wants to do something new because they haven't made enough mistakes yet.
Or alternatively they've seen the millions of issues you can get with sysvinit scripts that aren't perfect and decided we can do something better.
