Hacker News new | ask | show | jobs
by yellowapple 4017 days ago
The nice thing about initscripts, though, is that you can get the best of both worlds by sourcing in common functions, as is the default and recommended practice on OpenBSD. For example, here's the initscript for dovecot on my (OpenBSD-running) mail server (with some comments and newlines omitted for brevity):

    daemon="/usr/local/sbin/dovecot"
    . /etc/rc.d/rc.subr
    rc_cmd $1
Pretty straightforward: you set $daemon to the path of your daemon's executable (in this case, dovecot), source in rc.subr, and call rc.subr's rc_cmd command with $1 (which represents a command, like 'start', 'stop', 'restart', etc.).

rc.subr, meanwhile, holds all the complexity one will ever likely need in an initscript, in the form of various shell functions encapsulating things like starting, stopping, etc. And if that's not enough for whatever reason, it's easy to add more functionality either to the individual initscript or to rc.subr, since it's shell scripts all the way down. In my experience, reasoning about this sucks a lot less than writing a systemd unit file, let alone an initscript on a system without such niceties.

1 comments

That is the crazy part, systemd at its core is a reaction to sysv (and upstart).

In part part the reaction is to the boilerplate nature of sysv scripts, as they bring all their logic with them.

but if you glance outside the RH/Debian sphere you find the likes of Slackware, that has been using BSD style init for decades.

Slackware's a bit of a peculiar case. It does indeed use /etc/rc.d in a somewhat-BSD-style manner, but there are two key differences:

* Slackware doesn't use a BSD-style /etc/rc.conf. Instead, daemons are enabled/disabled by setting the executable flag on each initscript. While this loses some of the features of /etc/rc.conf, I personally like this method better.

* Slackware doesn't include an equivalent to /etc/rc.d/rc.subr, which means there's a lot of boilerplate in its initscripts.

But yes, systemd's primary objections to shell-based init systems in general seem to stem from a limited scope.