Systemd, an alternative to Upstart or System V init, has made big
strides since it was announced at the
end of April. It has been packaged for Fedora and openSUSE, and for users
of Fedora Rawhide, it gets installed as the default. There are still bugs
to be shaken out, of course, and that work is proceeding, especially in the
Rawhide. The big question is whether Fedora makes the leap to use
systemd as the init system for Fedora 14.
When last we looked in on
systemd, Lennart Poettering intended to have a package ready for Fedora
14, which has happened, but it was unclear what, exactly, openSUSE's plans
were. Since then, Kay Sievers, who worked with Poettering on
developing systemd, has created an openSUSE Factory—essentially the
equivalent of Fedora's Rawhide—package along with web page of instructions for
interested users. But most of the action seems to be going on in Fedora-land.
The Rawhide package gets installed in parallel with the existing Upstart
daemon, so users can switch back and forth. That's important because of
some glitches in the systemd installation that require users who upgrade
from earlier Rawhides to manually
enable certain services and targets:
# systemctl enable getty@.service prefdm.service getty.target \
rc-local.service remote-fs.target graphical.target
(The last "graphical.target" entry comes from a second message
and will resolve the common
"Failed to load configuration for default.target" problem).
The magic incantation to switch between the two is detailed in a fedora-devel posting announcing that systemd was made the
Rawhide near the end of July. The kernel command line init
parameter can be used to choose either systemd
(init=/bin/systemd) or Upstart (init=/sbin/upstart); as
Poettering points out: "note the /sbin vs. /bin!"
There are various other problems being reported on fedora-devel as well,
from the network not coming up
automatically to shutdown behaving
strangely. The fixes are generally straightforward, for the network it
is a simple matter of doing:
# systemctl enable NetworkManager.service
# systemctl start NetworkManager.service
and the shutdown problem was addressed by Poettering in the systemd git repository
within a few days of the report. While he was congratulated for his quick
response on the shutdown problem, Poettering's responses on other systemd
breakage has caused some consternation among other Fedora developers.
In particular, a dubious interpretation of
the "noauto" mount option in /etc/fstab caused numerous
complaints. Essentially, that option is meant to tell the system that the
filesystem should never be mounted except by an explicit action of the
user. But the systemd developers decided that "noauto" just means
that the boot shouldn't wait for the filesystem to be mounted, but will still
proceed to mount them if present at boot time or plugged in later.
Poettering has changed systemd so that its "noauto" behavior matches
expectations—and the documented semantics—but some of his
responses rubbed folks the wrong way. Worse, though, is the concern that
Fedora will be making a big mistake by adopting systemd now, instead of
making it optional for Fedora 14 and then the default in Fedora 15 if all
is well. Matthew Miller voiced his
[...] When you're replacing a core
component of the OS, and you're faced with a point where a human interface
could be changed, the first thought must be "how can we make this
improvement with minimal disruption?".
So, my question is serious. If we go ahead with systemd for F14, will we be
hit with an onslaught of confusion, trouble, and change? That would be good
for testing systemd, but *not awesome* for the distribution or for its
users. Or, on the other hand, is it a matter of a few kinks which we can get
solved before release?
Poettering is characteristically optimistic
in response: "Quite frankly I'd draw a completely different conclusion of the current
state of affairs: everything is looking pretty great." He goes on
to note that any issues reported have been quickly fixed, and that the
number of bugs has actually been fairly small:
That all said if you have a look on the number and quality of open bugs
of systemd for F14 then it appears to be a lot stabler and more polished
than probably most of the stuff in the current base system. It's
definitely not a good metric, but I do believe if that even if the
number increases to a healthy level comparable with other core packages
we'd still be fine.
So, [breathe] deeply, and let's all be jolly!
He has also started a
series of blog posts to help administrators become familiar with systemd
and to ease their transition.
But his overall approach sometimes come under question. At least partially
because of the way he handled PulseAudio complaints, Poettering has
something of a
reputation for waving away bugs as features, which tends to irk some.
Miller puts it this way: "The
pattern I see is that each time, you respond initially with (paraphrased)
'It's not broken -- we've made it better!' before implementing the
The thread went on for quite a ways, even by fedora-devel standards, but
the crux of the issue seems to be that there are worries that major changes
that break things are chasing Fedora users away and a switch to systemd may
be just that kind of change. There is no hard evidence
of that, but it is clearly a fairly widespread—though not
universal—belief. To try to escape the flames and assist with
moving the decision about using systemd as the default in Fedora 14 to a
technical, rather than emotional, basis, Bill
Nottingham started a thread about
acceptance criteria for systemd: "From [reading] the thread, there
are many things that I think people would like covered with systemd before
they would feel comfortable with it. So, I'm going to attempt to quantify
what would need to be tested and verified."
As might be guessed, the flames didn't completely subside but the focus did
shift to technical considerations, with an emphasis on backward compatibility
to existing Upstart—and earlier System V
init—functionality. There are lots of moving parts that go
into making the transition from Upstart (which is mostly run in
sysvinit compatibility mode in Fedora currently) to systemd,
however, and Poettering is feeling like he is getting saddled with fixing
any and all problems, even those that are legitimately outside of
There is a difference between what the Fedora and systemd projects need to
do, though. As pointed out by several people, Fedora needs to ensure that
the system works well, regardless of where the problem lies. As
Nottingham notes, there is a higher burden
on the person pushing a major change, but the distribution as a whole needs
to get it
It's about the integration into the system. Playing a blame game doesn't
help... if the system doesn't work, we can't ship that way. If there are enough
blockers in other packages that prevent a systemd system from functioning to
these sorts of specifications, we cannot ship systemd. Period.
The onus is on the introducer of a large change to make sure that change
works in the system. Sure, we can fire up requests for help, we can lean on
people to fix their packages, and we've got people who are willing to help.
As he surely recognizes, Poettering's best strategy is to fix any bugs
found in systemd and any other component where he has time and enough
understanding to do so. Enlisting aid for any that he, or other systemd
developers, can't address seems appropriate as well. There is no one in
Fedora that can wave a magic wand and force developers to work on specific
tasks, so some amount of team building may be necessary. There is always a
hump to get over between the
development and deployment of a new feature, and the hump in this case is
larger than many. That said, none of the remaining issues looks so
daunting that they cannot possibly be overcome in the next few weeks.
The Fedora 14
schedule shows a "Beta Change Deadline" on September 14. On or before
that date, there will undoubtedly be a "go or no go" decision made on
systemd for Fedora 14. Between now and then, testing systemd, reporting
and perhaps more importantly, pitching in to fix bugs are all things that
systemd fans can do to push it forward. Otherwise, we may have to wait
until Fedora 15 to really see what systemd can do.
to post comments)