
Good news, everyone!
So as of last Sunday, this works on all Linux archs in Debian unstable and
gives you a modern version of upstart:
echo 'Yes, do as I say!' apt-get -o DPkg::options=--force-remove-essential -y --force-yes install upstart
Thanks to the ifupdown, sysvinit, and udev maintainers for their cooperation
in getting upstart support in place; to the Debian release team for
accomodating the late changes needed for upstart to be supported in wheezy;
and to Scott for his past maintenance of upstart in Debian.
Benchmarking
One of the consequences is that it's now possible to do meaningful
head-to-head comparisons of boot speed between sysvinit (with startpar),
upstart, and systemd. At one time or another people have tested systemd vs.
sysvinit when using bash as /bin/sh, and upstart vs. sysvinit, and systemd
vs. sysvinit+startpar, and there are plenty of bootcharts floating around
showing results of one init system or another on one distro or another, but
I'm not aware of anyone having done a real, fair comparison of the three
solutions, changing nothing but the init system.
I've done some initial comparisons in a barebones sid VM, and the results are
definitely interesting. Sysvinit with startpar (the default in Debian) can
boot a stock sid install, with no added services, in somewhere between 3.37
and 3.42 seconds (three runs). That's not a whole lot, but on the other hand
this is a system with a single filesystem and no interesting services yet. Is
this really as fast as we can boot?
No, even this minimal system can boot faster. Testing with upstart shows that
upstart can do the same job in between 3.03 and 3.19 seconds (n=3, mean=3.09).
This confirms what we'd already seen in Ubuntu, that it makes a difference to
boot speed to have filesystem mounting handled by an integrated process that
understands the whole system instead of as a group of serialized shell
scripts.
What about systemd? The same test gives a boot time between 2.32 and 2.85
seconds (n=4, mean=2.48). Interesting; what would make systemd faster than
upstart in sid? Well, a quick look at the system shows one possible
contributing factor: the rsyslog package in Debian has a systemd unit file,
but not an upstart job file. Dropping in the
/etc/init/rsyslog.conf from
Ubuntu has a noticeable impact, and brings the upstart boot time down nearer
to that of systemd (2.78-3.03s, n=5, mean=2.92). Besides telling me that
it's time to start spamming Debian maintainers with wishlist bugs asking them
to include upstart jobs in their packages, this suggests that the remaining
difference in boot time may be due to the outstanding init scripts in rcS.d
that are made built-in no-ops by systemd but not (yet) by upstart in Debian
(e.g.,
hwclock,
hostname,
udev-mtab). (In Ubuntu, /etc/rcS.d has long
since been emptied out in favor of upstart jobs in the common case, since the
time it takes to get to runlevel=2 is definitely a major issue for boot speed
and boot parallelization.)
It also gives the lie to the claim that's been made in various places that
spawning shells is a major bottleneck for upstart vs. systemd. More study is
certainly needed to confirm this, but at least this naive first test suggests
that in spite of the purported benefits of hard-coding boot-time policies in C
code, upstart with its default degree of runtime configurability is at least
in the ballpark of systemd. Indeed, when OpenSuSE switched from upstart to
systemd, it seems that something else in the stack managed to
nullify any
benefit from
improving the boot-time performance of apparmor. Contrary to what some
would have you believe, systemd is not some kind of silver bullet for boot
speed. Upstart, with its boot-time flexibility and its long history of
real-world testing in Ubuntu, is a formidable competitor to systemd in the
boot speed department - and a solid solution to the many longstanding
boot-time ordering bugs in Debian, which still affect users of sysvinit.
I've published the bootcharts for the above tests
here. Between the
fact that Debian's bootchart package logs by default to /var/log/bootchart.tgz
(thus overwriting on every boot) and the fact that these tests are in a VM, I
haven't bothered to include the raw data, just the bootcharts themselves. The
interested reader can probably generate more interesting boot charts of their
own anyway - in particular, it will be interesting to see how the different
init systems perform with more complicated filesystem layouts, or when booting
a less trivial set of services.
Other musings
The boot charts have been created with the
bootchart package rather than
with
bootchart2. For one thing, it turns out that
bootchart2 includes
systemd units, not init scripts; so when replacing bootchart with bootchart2,
the non-matching init script is left behind and systemd in particular gets
terribly confused. This is now reported as
Bug #694403.
In an amusing twist, while I was experimenting with bootchart2, I also
noticed that having systemd
installed would slow down booting with other
init systems, because systemd installs udev rules which take a noticeable
amount of time to run a helper command at boot even though the helper should
be a no-op. So if you're doing boot speed testing of other init systems,
be sure you don't have systemd on the system at the time!