Re: Bug#727708: init system thoughts
Colin Watson wrote:
> (Now, I've been working with Upstart's model for years, and it's now a
> pretty fundamental way of how I think of system operation; so if people
> who are new to *both* models rather than partisans of one side or the
> other consistently tell me that the systemd model is easier to grasp,
> then I'll listen.)
I'd like to respond to this point, since I have a clear memory of
dealing with both upstart's model and systemd's model for the first
time. I also work professionally with a system (ChromeOS) that uses
upstart, and I've dealt with systemd quite a bit as well. For the sake
of full disclosure, my position is that I'd prefer systemd over upstart;
I'd be OK with upstart if and only if systemd remained a viable
alternative (in other words, packages maintaining both upstart jobs and
systemd units but not necessarily maintaining init scripts seems pretty
reasonable). So, at this point I'm squarely in the systemd camp, but
not for any particular reasons of partisanship; I simply find the
technology and model better.
I started out dealing with the sysvinit model, pre-startpar; I dealt
quite frequently with the magic ordering numbers (S20, K80, etc). My
first exposure to dependencies was through startpar and LSB, and they
made sense, though I was never a fan of the magic 'S' runlevel. I
fairly quickly saw that mapping those dependencies to script ordering
numbers was a hack, albeit a nicely done hack for compatibility; using
the dependencies natively made a lot more sense, though.
I read about upstart when it was first announced, and I dove into the
event model quite extensively, thinking that it might help improve
things. I never found it particularly intuitive, and in particular the
whole "start on starting", "start on stopping" etc model never really
made much sense to me; it didn't seem like a natural mapping of how the
system worked. I also, from the beginning, disliked the model of
starting everything that was possible to start, though I did not at the
time see what the alternative would be; it simply never really seemed
like the right model for booting quickly. (This was reinforced when I
started paying attention to boot time, inspired by the original "boot in
5 seconds" presentation; upstart's model seemed entirely unsuited for
that exercise.) I also found the requirement to know how many times
your daemon forked quite obnoxious (even more so the failure mode if you
get it wrong on even one daemon). These days, dealing with upstart
professionally, it still seems entirely too easy to get upstart confused
and in a difficult to recover state via a single incorrect upstart job,
and I find it one of the most annoying subsystems to deal with; there's
a general feeling of "oh, joy, that's probably an upstart issue" every
time any issue relating to booting comes up.
By contrast, my initial exposure to systemd (via the "systemd for system
administrators" blog series and the systemd documentation) was actually
via socket activation, with the dependency mechanism coming later. The
socket activation model, as a replacement for dependencies, was one of
those rare ideas that seemed immediately obvious in hindsight. My
introduction to systemd's dependencies was more along the lines of "and
explicit dependencies exist for when you can't fix your daemon and unit
file to do things the *right* way". Similarly, the use of autofs and
other techniques to allow starting things in parallel even when
dependencies exist made immediate sense. And the entire model,
including its handling of asynchronous events (notably the integration
with udev), simply felt like a closer fit to how the kernel works and
how reality works. Finally, the concept of factoring out common
elements from daemons seemed quite nice, having dealt with quite a bit
of ugly boilerplate code.
In both cases, I had no particular reason to like or dislike either
model; in each case I very much *wanted* them to work out, since my
exposure to sysvinit versus startpar gave me a very early reason to want
something better than sysvinit. I had no other reason to prefer one
model over the other. I'm not attached to either init system, nor do I
have any particular bias or reason to favor one over the other for any
reason other than superior technology or a model I find clearer and more
natural.
So, in summary, upon initial introduction, I found systemd's model far
more intuitive, both innately (in its use of socket activation and
similar mechanisms to *avoid* dependencies) and as a more natural
mapping to how the system, kernel, and hardware work.
I hope this writeup of my first impressions of both systems proves
useful in some way.
- Josh Triplett
Reply to: