Those old init scripts were pretty boilerplate and not that hard to write. And in the case of OpenBSD (and maybe other BSDs?) the scripts for /etc/rc.d are usually just a few lines.
With the traditional init system I knew what was going on, and if I didn't, find and grep were your friends. With systemd I'm googling everything every time. The systemctl man page is over 1,100 lines. OpenBSD's rcctl man page is 119 lines.
I'm sure there are use cases for systemd but for running a server that provides a single or a handful of services, it seems like complete overkill.
In the GNU/Linux world, yep, this is the case. Lots of copypasted boilerplate that becomes a nightmare to debug.
In the BSD world (at least with OpenBSD, where I'm most experienced), this isn't the case at all; OpenBSD ships with /etc/rc.d/rc.subr, which one can (and should) source into one's initscripts to make life much easier than even (in my experience) systemd's unit files. Set the $daemon variable, source in rc.subr, call rc_cmd, done. Sure, you might want/need to read a couple manpages, but this is the case with systemd, too.
Back to the GNU/Linux world, the complexity of SysVInit is not a hard dependency of using shell scripts for daemon management; there's very little stopping a GNU/Linux system from adopting a BSD-style rc system, rc.subr, etc. and making life significantly easier for sysadmins. Alternately, there's very little stopping a GNU/Linux system from implementing shell scripts in something significantly less horrendous to use, such as an interpreted scripting language (like Perl or Python or Ruby). SysVInit and BSD-style rc-based init both have a distinct lack of hard requirements on how initscripts are implemented, so long as said scripts are valid executables.
> Maybe there's something to be said for "sysadmins who want to be able to model the entire boot process and run-state in their head" but with correct information about dependencies and so on, I personally think that's something computers are a lot better at solving.
Would you not want to be able to model the startup process and run-state of the software you write in your head? Why should the underlying operating system be any different? If you have to rely upon external tools just to be able to reason about the execution flow of something - your server, your program, your recipe for lamb vindaloo, whatever - chances are it's way too complicated and needs significant refactoring.
I also find this a peculiar thing to say. Systemd replaces a few thousand lines of shell scripts and several dozen small well-tested binaries (i.e. coreutils and friends) with a suite of tightly-coupled daemons and tools written in a few hundreds of thousands of lines of C. They haven't removed the "jumbled mess" or made the implementation less complex; they've just hidden it away inside opaque binaries.
I'll grant that LSB sysvinit scripts aren't the easiest on the eyes, but they're hardly the shining example of what a scripted init system can look like. OpenBSD's rc scripts are far more elegant and just as featureful, IMHO.
It's been a number of years - doesn't openbsd use just plain /etc/rc and /etc/rc.conf? I like that better than init.d just because it enforces some standards around the scripting at least.
I admin a number of ubuntu servers running systemd, and they all shut down/reboot pretty much instantaneously.
Writing init scripts is as hard as you want it to be.
and 99% of sysadmins are not writing their own, they're modifying the ones supplied by distro maintainers.
If you're a distro maintainer then init scripts are something you write, something you understand because you're handling the state of your distribution from them.
Of course you can just abstract away all the code to another bash script and have your init as 2 lines (which is what openBSD actually does).
> sysvinit was at least a thousand times easier than bsd init scripts
¿Qué?
I guess we'll have to beg to differ here, but I prefer OpenBSD's (for example) init system over sysvinit or systemd any day. rc.subr is a godsend for eradicating all the boilerplate that "justified" switching to systemd. Enabling/disabling a daemon is as easy as adding a line to /etc/rc.conf.local (or just running "rcctl enable mydaemond", which does that for me). No fiddling with symlinking scripts to runlevel-specific folders (or, in fact, dealing with runlevels at all; if I need single-user mode, that's what bsd.rd is for).
One of these days I'd love to start ripping out the initscripts on my Slackware machines and replace them with something closer to OpenBSD (or hell, I wonder if I can just port OpenBSD's init to Linux?).
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]
Boot times, although obviously benefited by inetd and parallel execution, were already improved significantly by the LSB-standardized init headers and the insserv mechanism to interpret them. Debian, Red Hat/Fedora, openSUSE, etc. all used them, to the best of my knowledge.
Also, the bad reputation around initscripts is, again, a SysV issue. Here is the rc script for sshd on OpenBSD:
Nothing there follows from what I wrote, or even from what you yourself wrote earlier, for that matter; and the idea that the difference between inittab and rc is "minimal", when the quite marked difference between init and rc has been a fundamental Unix thing since First Edition, is laughable and gives away the entire lack of foundation here. One never has "written shell scripts for init", moreover. You really do not have any sort of grasp of what you are talking about, and the "hating systemd" strawman that you just introduced out of thin air to then argue against is indicative of at best a lack of technical points to make.
I think RC was only simple if you stuck to a single distro and had a neatly predefined pattern of work.
It's true that systemd is nowhere near as easy to hack/get into but at the same time I find that the largely consistent definition language/CLI give me a lot less reason to want to do so.
When the need does arise, there's usually a line or two I can add to my service definition to get it to do what I want.
If that complexity isn't exposed, then it isn't more complicated. Lots of init scripts used to be quite different across distributions and very long. Nowaways the systemd unit files are shipped upstream and you just package them. That's vastly less complex.
Did you notice I haven't mention systemd in my comment at all? And other than this first sentence, I am not going to mention it in this comment at all.
The important thing is not who won, but the fact that the idea of writing init scripts in bash/sh has lost. Almost no one wants to maintain yet another incomplete or buggy shell script implementating of "start", "stop" and "status" commands. It is declarative way now - somehow define the command, arguments, user etc.. and let init system handle start/stop.
(Yes, there are still ancient systems like Slackware which use plain bash and have no plans to change. But even FreeBSD is pushing toward declarive: look at [0], does this look like a simple shell script which makes it cleat what's going on?)
That's why the people who advocate sysvinit get so little support. Try advocating for runit or daemontools or launchd or openrc or even SMF ( :) ), this will get you further.
I've written many init scripts for SysV, upstart, OpenRC and FreeBSD's rc, but I've found that systemd's service units to be by far the cleanest and quickest way to muster up an init script (with FreeBSD's rc in second place).
Also speaking as a sysadmin, I've found "every way" to be inaccurate. Initscripts have their limitations, but the most glaring issues with them (lots of boilerplate, hard to write, etc.) have been resolved in BSD Land for quite a while, thanks to things like rc.subr.
systemd does have some nice features that I've come to appreciate on my GNU/Linux boxen, but I'm still not exactly sold when my OpenBSD boxen have a mostly-sane rc system not subject to most of the problems the systemd crowd claims are inherent to initscript-based systems.
Having worked with inits of BSD, sysv, upstart, systemd, and launchd varieties, I strongly prefer the administrative and debug capabilities of the script-oriented ones.
BSD's choice to drop everything into a single rc file is not particularly elegant, but it can be coerced to do what you want. The sysvinit user interface, frankly, isn't bad:
I've been known to copy the files elsewhere to work with them, if necessary. The last time that was necessary was well over a decade ago. As a sysadmin (1 - 15k boxen), broken init scripts simply weren't on my radar. (Neither was boot time, or network management, or device management, or logfile management, or ....)
I'll add that my distro of choice is Debian (or derivatives, which I generally mean here). One thing that I noticed when first switching to Debian, back in the mid 1990s, was that its init scripts were vastly easier to follow than Red Hat's. Debian has a fairly standard structure (/etc/init.d/skeleton is the bare-bones template), and most scripts follow that within some reason. There are a few exceptions -- scripts which initialise things (bootclean, mount, networking) rather than start services, tend not to look like service initialisation scripts, on the inside. On the outside, though, they do.
Further: once configured properly, those scripts don't change. Debian in particular does an extraordinarily good job of extracting out all necessary configuration to an /etc/ configfile (which it then won't touch unless you specifically tell it to).
My experience on MacOS (see elsewhere in this thread) is that stuff which ought be easy isn't. My experience with systemd, to date, hasn't evidenced this, as I am largely using the extant sysvinit scripts. But I've noticed numerous things Wot Used To Work ... do not. And the response from the sysvinit devs, particularly from the top, as well as various sycophants on numerous fora, has been exceedingly disturbing.
Case in point, my single most controversial Reddit comment:
Linux did kind of get the short end of the stick with System V initialization. BSD rc scripts are also written in shell, but much cleaner (particularly when you make use of rcorder(8) dependencies).
systemd's declarative unit file syntax is easier to reason with, but comes at the expense of having to memorize a ton of options and being fundamentally dependent on the toolbox provided to you by systemd, since you can't code your way out of unconventional corner cases as easily.
The unit file syntax isn't the reason people complain, though.
With the traditional init system I knew what was going on, and if I didn't, find and grep were your friends. With systemd I'm googling everything every time. The systemctl man page is over 1,100 lines. OpenBSD's rcctl man page is 119 lines.
I'm sure there are use cases for systemd but for running a server that provides a single or a handful of services, it seems like complete overkill.
reply