Feature changed by: Andreas Jaeger (a_jaeger)
Feature #305690, revision 90
Title: Replace System-V init with upstart init
openSUSE-11.2: Rejected by Stephan Kulow (coolo)
reject date: 2009-08-12 11:32:51
reject reason: too late for 11.2 and still not seeing the benefit.
- openSUSE-11.3: Evaluation
+ openSUSE-11.3: Rejected by Andreas Jaeger (a_jaeger)
+ reject date: 2010-10-27 11:26:23
+ reject reason: Not done, it's an alternative only.
Requested by: Vitaliy Tomin (highwaystar)
Upstart - an event-based init daemon. It can provide more flexible init
system for more faster and effective boot and communication with the
init daemon over D-Bus. upstart home page http://upstart.ubuntu.com/
#1: Stephan Kulow (coolo) (2009-02-09 15:33:47)
why do you think it would be faster or more efficient? where do you see
#29: Robert Davies (robopensuse) (2009-12-10 17:39:39) (reply to #1)
Fresh install of Kubuntu 9.10, on my 64 bit box boots in very similar
time to oS 11.2, though the time without any visible indication of
activity seems longer than is comfortable.
What is faster, is actually the shutdown. But 11.2 shuts down pretty
snappily, so I'm not sure there's any real user benefits.
A reason not to implement this, might be the stuff that's going on in
kernel with devtmpfs, and HAL being deprecated; if the underlying
features are changing, retaining a stable boot process above it, would
be wise, to speed fault recognition.
#2: Dmitry Mittov (michael_knight) (2009-02-20 17:45:56)
It is not much faster. But it is not slower. And it is easy-to-use. As
I know init scripts has no requirements. It can start some daemons in
parallel mode if they have the same prefix S##. Imagine that daemon A
requires daemon B. Daemon B have the same prefix as C and they start
parallel. If daemon B starts fast & daemon C starts slow then daemon A
will wait daemon C though it doesn't require it.
In my opinion the main advantage of upstart is it's functional syntax
copmaring to classic init.
#3: Georg Müller (georgmueller) (2009-04-27 12:11:44)
One interesting feature is that it is event-based.
So it is possible to start or stop services on certain (dbus,hal,...)
#4: T. J. Brumfield (enderandrew) (2009-06-13 20:45:45)
Fedora and Ubuntu are both boasting really fast boot times due to
Upstart these days.
#10: Georg Müller (georgmueller) (2009-09-06 18:18:03) (reply to #4)
debian is switching, too.
#11: Stephan Kulow (coolo) (2009-09-07 10:23:28) (reply to #10)
oh, we will switch too (not all of debian's reasons apply to us, but
some important ones). But not in 11.2 timeframe.
#12: Georg Müller (georgmueller) (2009-09-07 13:52:45) (reply to #11)
No question that it is too late for 11.2.
I just wanted to mention this here, because the article includes some
of their reasons.
#5: Georg Müller (georgmueller) (2009-08-05 03:08:21)
Hm, looks a bit late for 11.2 to change, though there is a compat mode
#6: Ralph Ulrich (ulenrich) (2009-08-05 14:00:55)
For getting a faster boot there are two different ways to consider:
1. get rid of waitings/loops
2. get rid of unnecessary services, start them later only if they are
Upstart is an additional layer and therefore adds to point 1. Upstart
will be fine with point 2 if the necassary features are implemented
#7: Georg Müller (georgmueller) (2009-08-05 14:39:44) (reply to #6)
Well, init runs anyway. upstart init might be a bit larger, but not
current init VSZ/RSS is 1772/772
upstart init VSZ/RSS is 5244/576 (checked on an ubuntu 9.04)
I see a future benefit with no drawback for the moment.
If the big distros (or most of them) will switch to upstart, package
maintainers might provide event configs (for /etc/event.d) in addition
to the traditional init scripts. Then, the benefit of upstart can be
To sum it up, even if it brings no benefit at the moment, it will help
to bring benefits in the future without drawbacks for the moment.
#8: Stephan Kulow (coolo) (2009-08-12 11:33:47)
still looking for a volunteer to prove that it changes anything
#9: Ralph Ulrich (ulenrich) (2009-08-12 13:13:19) (reply to #8)
Why now a volunteer (feature is rejected for 11.2) ?
And no, it shouldn't change anything as it should be fully compatible
But you would be able to provide extra features (similar to inetd and
more) in future...
#13: (kamikazow) (2009-10-11 12:18:31) (reply to #8)
Upstart in "compatibility mode" (ie. justg using the old scripts)
probably doesn't change much, but if you want proof for old-style init
vs. an event-based one, get a PPC Mac and boot Mac OS X 10.3 and then
10.4. Don't know about Upstart, but at least OSX's launchd helped a
lot. If upstart doesn't help, launchd can be adapted as well (it's
#16: Luc de Louw (delouw) (2009-10-31 09:31:42) (reply to #13)
Please no lauchd... All other distributions are switching to upstart.
If replacing SysVinit please the same solution for all distributions
and it currently looks good for upstart since all major distributions
are switching to it.
#14: (ulenrich) (2009-10-11 14:13:50)
Nico Schottelius wrote (Debian mailing list):
I think seperating the bootup phase ("startup reliable and fast") from
the normal running phase ("events are triggered") is important:
An event system (like udev/hal) has to be very smart and provide good
interfaces to other systems (like UIs, logging, etc.).
An init system on the other hand should imho be as dumb as possible
(providing a fast and reliable startup) and provide simple APIs to
change the status of a service.
#15: (ulenrich) (2009-10-11 14:19:13) (reply to #14)
For the booting stage openSUSE uses an extra /etc/init.d/boot.d
This indicates the booting stage is easy delimitable.
Using two different tools for two different purposes would widen
general acceptance in use.
And probably this would unclutter upstart from all special booting
#17: Christian Jäger (eet) (2009-11-01 16:29:58)
This feature-request is another good example how pure pig-headedness
determines what features get actually included and don't.
Here we have a useful feature, the merits of which all other major
distributions have long since seen, and our friend coolo just
While dangerous and de-motivating nonsense like KDE-preselection on
install does get voted through without second thoughts.
I'm frankly despairing a bit about openSUSE management these days.
#21: Stephan Kulow (coolo) (2009-11-01 20:57:29) (reply to #17)
for someone not caring I comment a lot in here, no? For someone who's
looking for arguments, you're pissing a lot on others doing the actual
work. Did I block a patch from you? Not afaik.
#22: Christian Jäger (eet) (2009-11-01 21:58:02) (reply to #21)
Your comments were:
1) why do you think it would be faster or more efficient? where do you
see the gain?
2) still looking for a volunteer to prove that it changes anything
and then, all of a sudden:
3) oh, we will switch too (not all of debian's reasons apply to us, but
some important ones). But not in 11.2 timeframe.
That was obstruction until obvioulsy someone else seems to have given
the whole thing a 'go'. That does not count as 'caring' about the
When the openSUSE project started out, I was enthused, did a lot of
beta-testing and contributed a bit, as far as non-programmers can. But
slowly the typical answer that I received when filing bugs got to me:
The habitual stance of openSUSE staff seems to be 'why? we don't need
that' and this (and of course the whole story of the so-called 'feature
request' "make KDE king") has really, really pissed me off. So
get holy with me.
#23: Stephan Kulow (coolo) (2009-11-02 10:25:13) (reply to #22)
"openSUSE staff"? You really understood how open source projects work I
#24: Christian Jäger (eet) (2009-11-02 22:40:06) (reply to #23)
Yes, you're right; I unfairly took out my frustration on you. I no
doubt wanted to see some behaviour resembled here that I resented some
#18: Christian Jäger (eet) (2009-11-01 16:33:21)
@coolo: It would do you good to read c't from time to time:
Schneller booten mit Upstart
#20: Stephan Kulow (coolo) (2009-11-01 20:55:53) (reply to #18)
I'm afraid the author is a journalist not an engineer. Already the tag
line " Ein Großteil der Bootzeit heutiger Linux-Systeme geht für die
Systeminitialisierung und den nicht-parallelisierten Start Dutzender
von Daemons drauf." -> wrong, openSUSE boots parallel since 8.2. Just
because ubuntu didn't before upstart, doesn't mean switching to upstart
will gain anything.
#26: Georg Müller (georgmueller) (2009-11-03 19:11:59) (reply to #20)
I thought that too then reading the article.
But if you compare a classic init script with an upstart config, the
upstart config looks so much cleaner:
You don't have to keep track for the state by your own (pid files and
so on), upstart keeps track of the state. Just as an example:
/etc/init.d/dbus (openSUSE 11.1): 124 lines /etc/init/dbus.conf (ubuntu
9.10) : 23 lines
Same with cron (160/14)
#19: Per Jessen (pjessen) (2009-11-01 17:32:24)
What would the impact on the many existing init-scripts be, if any?
Also custom non-opensuse scripts. Personally I don't have a need for a
faster booting system, but if it's achievable with a minimum of
effort/impact, then why not. Are there any other benefits beside
#25: Ralph Ulrich (ulenrich) (2009-11-03 02:56:47) (reply to #19)
If you run upstart like ubuntu jaunty in a sysv compatibily mode you
don't need to change anything. But you don't neet to run upstart
Ich you want to gain something from upstart you loose lsb standards ?
But Ubuntu karmic feels fast. And there are a bunch of
optional/possible gains : Think of mobile computing with changing
#27: Luis Medinas (lmedinas) (2009-11-24 20:05:21)
There are already up-to-date packages at
#34: Stephan Kulow (coolo) (2010-02-10 16:27:49) (reply to #27)
did you test them? do they work fine?
#28: Robert Davies (robopensuse) (2009-12-01 01:37:37)
We don't want to run Upstart in compatability mode with SysV init
scripts, that would be unproductive step as apart from being Event
based. we have most of touted advantages already. Debian startup
scripts were an unmaintainable mess, with packages fooling in other
packages, and Ubuntu/Debian don't have clear concept of run levels that
is very useful for sysadmins, rather than casual users. So it did
makes sense for them to propose a radical new method and sell it.
If Upstart is used, then a big effort is required to port over startup
files and really use it, where it makes sense. In long term with
Ubuntu, Debian & Fedora using it, then it'll make sense for
compatability reasons, and avoiding translation of Upstart scripts to
Sys V, or having difficulty with features written for even driven
system. Having 2 new systems in parallel will be confusing and likely
There's nothing wrong with being late adopters sometimes. I really
think Stephan Kulow is making very responsible and good points, the
burden of proof should rest on those wishing a change. With fine
examples surely the proponents can demonstrate documented improvements
and neat solutions.
Compatability mode is not a solution, it is duplication & bloat. When
I first heard about Upstart I was very interested, joined the mailing
list; that's because I prefered simpliciity of BSD to Sys V and Gentoo
had interesting take on startup to. Now with fast CPU, and SSD's
coming, the annoyances with SysV init are much less, and can enjoy the
#31: Ralph Ulrich (ulenrich) (2009-12-12 13:53:40) (reply to #28)
good points - I already tried to express in #25 that compatible mode of
upstart gains nothing.
In your last sentence you miss that upstart is also about dynamicly
triggered services not only fasten the boot.
Does someone know what about SysV and LSB ?
#32: Robert Davies (robopensuse) (2009-12-17 10:57:44) (reply to #31)
Event driven covers "dynamically triggered"
LSB was written to allow portably add/remove a service using a simple
defined command (allowing multiple implementations) that is technically
simple to fulfill once you have native distro packages providing
#30: Martin Christeson (mchristeson) (2009-12-11 21:23:47)
In 11.2 I am still seeing the iratic behavior with the shutdown GDM
race that was blocking at RC2 on some machines. If the events would
help with this type of interation, it would be useful.
(For those that doen't see this the problem was when in INIT 5 and a
user uses slab to shutdown, it closes the GUI and restarts GDM and on
some machines will just sit there. In one case I have, If I click on a
user and type a few charateres of the password, it will then change run
levels.). This has been through bugzilla a few times and the answers
haven't been able to address all use cases. An event based answer
would be a cleaner answer to the conditions that cause this type of bug
and provide an easier path to resolution when these conditions are
identified during integration testing.
#33: Karl Fischer (karlfischer) (2009-12-23 10:34:46)
I believe this could be valuable for Moblin / Goblin (Netbooks)
#35: Jakub Rusinek (liviopl) (2010-02-10 19:21:46)
To take the advantage, services would have to be events based
#36: Stephan Kulow (coolo) (2010-02-12 07:44:01) (reply to #35)
this is simply not true and I wonder on what informations you base this
#39: Jakub Rusinek (liviopl) (2010-02-12 15:27:18) (reply to #36)
Fedora and Ubuntu had to rewrite their init script to take advantage of
dependencies/events in services and use paralell booting of services.
I know Upstart is backwards compatible with SysVInit...
#37: Stephan Kulow (coolo) (2010-02-12 07:45:23)
Base:System now has an upstart package that does what fedora and debian
do too: start runlevels with upstart instead of sysvinit. We will test
this more and then ditch sysvinit and go with upstart.
#38: Stephan Kulow (coolo) (2010-02-12 08:08:02) (reply to #37)
what is left to do is porting ulimit package
#40: Robin Knapp (rknapp) (2010-03-28 17:58:55)
Looks like there is still much to to because inittab is not used
Just do a rpm -qa yast2\* | xargs grep inittab ....
#41: Stephan Kulow (coolo) (2010-03-29 11:02:36) (reply to #40)
what exactly are you missing? the inittab is still used e.g. to
configure the default init level
#42: Robin Knapp (rknapp) (2010-03-29 20:32:57) (reply to #41)
Yes, I've seen that in the config files.
But I guess there are many features in yast that edit the inittab
For example the yast security module can disable ctrl-alt-del shutdown.
Also the dbus rc script should issue the messagebus even - haven't
looked if this is already integrated, I just saw it in the confs.
I hope I find some time soon to collect all the places (the list above
is a good start) and create bug reports - or would one report for all
yast modules be enough?
What is the target level of integration in 11.3? Only rc scripts
without regressions (like the mentioned yast ones?)
#43: Stephan Kulow (coolo) (2010-03-30 09:54:54) (reply to #42)
even though the feature says "replace sysvinit", for now the target is
to be a drop in replacement. This means the upstart jobs would parse
inittab as configure source. So if there is a feature enabled/disabled
in yast, the upstart config should check and then disable ctrl-alt-
#44: Jörg Cassenns (cassens) (2010-05-01 23:17:49)
In a long blog entry, Lennart Poettering describes several problems the
init process faces. He also describes why, in his oppinion, upstart
does not solve these, before describing (yet another) sysvinit
replacement: systemd (http://0pointer.de/blog/projects/systemd.html
Systemd is much closer to launchd than to upstart, and he gives good
reasons for that.
Not saying that systemd is the solution to all problems, but maybe it's
good that we did not see much uptake on upstart in openSUSE yet.
#45: Jose Ricardo De Leon Solis (derhundchen) (2010-05-07 02:54:58)
(reply to #44)
Systemd does look indeed promising, well designed and all in all better
than upstart and sysV init. We should think about replacing sysV init
with systemd once the latter is stable enough. Kay Sievers could help
to make it happen.
#46: Sascha Peilicke (saschpe) (2010-06-24 18:51:34)
I'd also say that waiting for systemd should be worth it as the gains
of using upstart are little. Let's see how the Fedora guys manage to
integrate it in F14 :-)
#47: Georg Müller (georgmueller) (2010-07-08 10:37:52) (reply to #46)
Comparing the two I am also in favor for systemd.
Should there be a separate feature for this?