Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.
Theodore Ts'o <tytso@mit.edu> writes:
> On Mon, Oct 28, 2013 at 06:21:27PM -0700, Russ Allbery wrote:
>> Well, I've said this before, but I think it's worth reiterating.
>> Either upstart or systemd configurations are *radically better* than
>> init scripts on basically every axis. They're more robust, more
>> maintainable, easier for the local administrator to fix and revise,
>> better on package upgrades, support new capabilities, etc.
> Can you please go in to more detail why you believe this was true?
I think it's painfully obvious if you compare an init script to an upstart
or systemd configuration file for a simple daemon like, say, my lbcd
package.
For those who don't agree, please try the exercise of writing systemd and
upstart configuration files for some typical daemon package and look at
the number of lines of code in both and the behavior in edge cases (daemon
already running, daemon running but with no PID file because something
else deleted it, daemon part of a dependency chain that shouldn't fire
until the daemon is actually listening to the network, correct exit status
for various failure conditions, stopping the daemon when there is a user
process with the same name as the daemon also running, and the other cases
Policy says one must handle). Now compare the length of time it took you
to make an init script correctly handle all those cases versus how long it
took to write the upstart or systemd configuration. (Note that I have
found, IIRC, two different edge-case bugs in /etc/init.d/skeleton while
working on Debian, so even if you start from that file, which is only
applicable to a relatively narrow range of circumstances, you can still
fail edge cases.)
I have prior experience here both as Policy editor dealing with the Policy
sections related to init scripts and as a Lintian maintainer dealing with
Lintian checks for init scripts. Both of those experiences were, shall we
say, convincing.
Another way to look at this is that both upstart and systemd provide a
high-level programming language for writing init scripts. Not only does
it implement a higher level of abstraction, it's also better-suited to the
problem space because it's declarative rather than imperative. (systemd
somewhat more so than upstart, although that makes it somewhat more
awkward to use in cases where you really need to run some shell script on
various actions.)
As with any move to a higher-level programming interface, there are
drawbacks; if you really want to do your own memory management, you don't
get to any more. And as with most moves to a higher-level programming
interface well-suited to the task at hand, the advantages outweigh the
drawbacks. (And in this case, I'd go a step farther and say that I think
most of the drawbacks people cite around loss of flexibility are at least
arguably benefits. The world would be a better place with fewer init
scripts doing weird and unexpected things to paper over bugs better fixed
somewhere else.)
This really shouldn't be a particularly controversial stance. Ever since
Solaris SMF, various UNIX implementations have been abandoning traditional
init scripts for exactly these reasons. I really don't think that all
those completely independent technical teams, which at this point include
most major Linux distributions (counting OpenRC as another higher-level
implementation), are all wrong.
This is an area of personal interest of mine. I followed daemontools
development back when Dan Bernstein was tackling this same basic problem
in his distinctively radical way, and have subsequently been paying at
least casual attention to various different daemon management facilities
ever since. A lot of people have tried to solve various aspects of the
problem that init scripts are actually horrible at what they do, and the
solutions have been slowly improving and becoming more and more robust.
AFS attempted to solve this problem all the way back in the 1980s. Even
back then, it was obvious that init scripts were insufficiently powerful
to manage production services properly, hence the whole bosserver system
that persists in OpenAFS to this day and which, coming from MIT, you may
be familiar with. Not that I would advocate use of bosserver for anything
other than AFS these days, as there are now lots of newer technologies
that have surpassed it, although (relatively) secure network management of
services is still an interesting feature.
> The lsat time I played with Upstart, I saw a lot of policy moved from
> shell scripts into C code (which I would have to edit and recompile) if
> I wanted to change things. I also was extremely frustrated with a
> massive lack of documentation, where at least with shell scripts I could
> read the scripts to understand what was going on.
I suspect you and I have a root disagreement over the utility of exposing
some of those degrees of freedom to every init script author, but if you
have some more specific examples of policy that you wanted to change but
couldn't, I'd be interested in examples.
Note that *Debian*, as a distribution, has a significant interest in
standardizing policy around how daemons are managed. It's therefore not a
bad thing for the distribution if we have an init system that handles that
policy, provided that it encodes the policy that we want. I realize that
the local administrator may have other goals, and they should have ways of
achieving them, but both systemd and upstart support running SysV init
scripts for those cases.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: