Cover photo
Christoph Anton Mitterer
Works at Ludwig-Maximilians-Universität München
Lives in München
169 followers|367,728 views


That blog post is really interesting... and disturbing... in so many ways.

First, while I don't like everything about +systemd, I was/am in favour of it (as long as we can keep the non-Linux ports alive)...
Russ made a very good analysis some time ago, while it's simply better and I guess many people felt the core design of upstart to be broken, not to talk about some unpleasant long time bugs in it.
And I also agree with people like Ian or Andi , that it's bad if high
level software makes to strong bonds to such low level stuff (most
notably +GNOME).

I wasn't the only one who expected and posted here that  Debian's
decision would be also a decision about the fate of upstart,... +Ubuntu was/is the only bigger distro left, that used it as their current default init system... and even though +Mark Shuttleworth doesn't clearly say it... his post is most probably the death sentence for Upstart.

What I find quite amusing is that he claims it to be "truly great free
software", especially when one thinks that systemd might have never came into existence if there wasn't the CLA.

What's quite disturbing is, that he puts some focus on "+Bdale Garbee’s
casting vote" as if the whole thing was his fault and as if he'd make
him responsible.
Doesn't sound too friendly in my ears, to be honest,... but maybe it's
just some misconception.

But now there's the really interesting part:

Debian and it's community went through some bad weeks now, people
"shouting" at each other, TC members trying to remove others and so on.
What if upstart would have been dead already? I guess no big discussion would have came up!
Most people agree that sysvinit is legacy and as long as we allow the
non-Linux ports to continue with something else, these would have been happy as well.
And the discussion about init-system coupling is IMHO anyway a much broader one... it's more or less the same discussion whether a desktop environment should be allowed to strictly couple on something like NM, Avahi, etc..

Further, I'd guess that Mark wasn't caught by surprise with the
tech-ctte's decision. He might not have followed every tiny bit of the
whole lengthy story, but I'm sure he was aware.

Now either he believed in upstart and it's design and strengths and
hoped for it to win... and when he did that I really wonder why he gave
up now? Even before a not so unlikely GR.
Canonical has shown with mir that they have no problem to go a different way that what more or less everybody in the FLOSS world thinks is the right way... for whatever reasons (I don't know whether they have real technical reasons or others).
So if they'd have really believed in upstart, I'd have expected them to
continue now, especially when it seems that Debian will continue to
support it anyway (just not choosing it as the default init-system).

So that somehow makes me think: They didn't believe in it themselves and already new that systemd was superior, that upstart has design issues, etc. pp.

But then the question would be: why didn't they tell us in advance?
If it would have been clear that the main group behind upstart will
likely abandon it, all the discussions of the last week would have
likely been moot.
All the "upstart may be supported in freebsd in some near future" etc.
would have been pointless, since it would have been clear that upstart
will see a similar fate than bzr.

Now is that behaviour "nice" against Debian? I don't think so.
And once more it makes me question, whether the Debian/Ubuntu
relationship is really that healthy for Debian in all areas.
Undoubtedly there are areas where Debian benefits... but given that it
often seems that Canonical wants to drive Ubuntu rather in a lone
island/hype experience than all these iOS, Chrome OS, etc. out there...
I doubt that it's healthy for Debian on a broad view.

btw: And quite obviously, this post is not about bashing upstart,.. to
me it seems actually as if they'd be kinda betrayed by their very own
BDFL... and undoubtedly they did some great job in showing ideas for a
better init-system than sysvinit was, which is IIRC even admitted by the systemd upstream.
Add a comment...
A large group of crypto and security researchers published an open letter this week denouncing the NSA's attempts to deliberately sabotage information security.
Add a comment...
So it appears that the Debian ctte discussions are now stuck at a 4:4 stalemate between systemd and Upstart.

What I find interesting about this, is that during the discussions some of the most fundamental questions were never asked: do the three contenders actually do what one would expect from a modern system that brings up the system and manages services? Are they substantially better than what sysvinit provided?

When looking at the boot process of modern computers, there are some bits that are certainly more important than others. One of the most important ones is getting the logic right how file systems are set up: the system needs to wait until all block devices from /etc/fstab have shown up, have been fsck'ed and have been mounted. Only after this has been done for all file systems listed boot may proceed.

On sysvinit this crucial part of the boot process was very poorly implemented: there was simply no scheme in place to wait for the devices from /etc/fstab to show up. Instead, through a mix of sleeping + "udev settle" + scsi_wait_scan the system would wait for a point in in time where "all" devices have shown up, then it would fsck them all, and then it would mount them all. This scheme worked fine on 90's hardware, since all hard disks were local and storage systems simple: it would be unlikely that devices would not have been found and probed within that magic sleeping interval. However, this is really not how modern computers work. Nowadays pretty much all hardware is hotplug capable, and for most hardware there is no time guarantee whithin which all connected devices have to have shown up (and this can get quite bad, for example on USB or iSCSI, or RAID stuff). Thus, any scheme that doesn't take into account which the devices are that need to be waited for, is simply unreliable and slow (since one doesn't know how long to wait, one has to wait for longer than really necessary). Reliability is crucial for server setups, and boot times for client machines. sysvinit is good at neither.

Now, when we look at the three contenders, we notice that one of them brings exactly nothing to the table here that is any better than sysvinit here: OpenRC does not understand /etc/fstab, it has no facility to wait for the devices listed in them, fsck them, mount them.

Upstart is much better here: it contains a binary called "mountall" that will wait for the devices in /etc/fstab to show up, will fsck them and mount them. So on the first peek everything is fine, it should be sufficient to just call this at boot and all is good, right? Well, in a way that's true, however I think the existance of this tool exemplifies, illustrates like little else how insufficient and broken the basic Upstart design actually is: even though Upstart is "event-based" and all, the most crucial, relevant part of the boot process it cannot cover: the waiting/fscking/mounting takes place completely outside of Upstart's rules engine.  The Upstart developers resorted to a completely external state machine for the most important part because they coudln't map it to Upstart's design. But what good is the design if it cannot even cover this central part of the boot process?

(I figure I don't have to mention this: systemd OTOH will parse /etc/fstab, and integrates its contents neatly into the dependency tree as little more than just another source of configuration.)

The existance of mountall on Upstart, and the non-integration of /etc/fstab into the Upstart rule set, results in a lot of additional shortcomings: mountall is a one-time thing for the boot process, all context of file systems, devices and mounts is lost, after it ran, and the file system state is henceforth assumed static. Which of course is not how systems work these days...

This design flaw is one of the things we noticed when we looked into Upstart in detail before we decided to start systemd. 4 years later, nothing has changed, the Upstart design still cannot cover this...

And there are more low-level questions like this one should ask, that should appear as absolute baseline what to expect from an init system. For example:

a) Does the init system support auto-respawning of services on failure/coredump/..?

b) Does the init system record exit status/signals/coredumps of services for later retrieval by the admin?

c) Does the init system record stdout/stderr of all system services for later retrieval by the admin?

d) Does the init system support timing out all service operations such as start or stop?

e) Does the init system support rate-limiting all service operations such as start/.. ?

f) Does the init system support basic resource management operations for services, for example, limiting CPU usage, memory usag, IO usage of a service, and so on?

And so on... Of course, systemd will cover all of the above fine, since we wrote it specifically with an enterprise usecase in mind, which needs to cover all of this. Note that the the points raised above are hardly something of the fancier features of systemd, they are really just the absolute baseline a service manager should cover. OpenRC falls short on most of these, Upstart faires considerably better, but it certainly doesn't cover it all...
Add a comment...
Hey friends and followers.

Apparently the OpenBSD Foundation hast some funding issues (, which I’ve stumbled over today, when reading about it ( at

Having OpenBSD is not only important for Open Source diversity, but the foundation is also behind OpenSSH and some other well known projects.

So if possible, consider a donation, as I just did.
Add a comment...
1/2 air & 1/2 water
Cesare Delle Fratte's profile photo
Add a comment...
Have him in circles
169 people
Helmut Heller's profile photo
Antje Petersen's profile photo
Dmitry Litvintsev's profile photo
This was a tough decision to make for Ubuntu! I am pretty sure it wasn't easy for them. I certainly believe it is the right decision, of course.

I'd like to welcome Ubuntu to the +systemd community! I am looking forward to a fruitful collaboration! Let's hope we can leave the past behind us, and work together in future!
Add a comment...
A large group of crypto and security researchers published an open letter this week denouncing the NSA's attempts to deliberately sabotage information security.
Add a comment...
Make it so! Make it so! Make it so!
Peter Kossatz's profile photoHeinz Schmidt's profile photo
Peinlich... Brrrrr.
Add a comment...
Have him in circles
169 people
Helmut Heller's profile photo
Antje Petersen's profile photo
Dmitry Litvintsev's profile photo
Computer Scientist
  • Ludwig-Maximilians-Universität München
    Diplom-Informatiker (FH), 2008 - present
  • Forschungsneutronenquelle Heinz Maier-Leibnitz (Forschungsreaktor München Ⅱ)
    Student, 2002 - 2011
  • Leibniz-Rechenzentrum der Bayerischen Akademie der Wissenschaften
    Student, 2004 - 2011
  • Siemens
    Student, 2007 - 2007
Basic Information
Other names
Cálestyo, Nótendil
Cálestyo Nótendil
I’ve studied computer science / informatics in München and work now at the LMU, mainly for the LHC Computing Grid.
Map of the places this user has livedMap of the places this user has livedMap of the places this user has lived
Burgkirchen an der Alz