Mailinglist Archive: opensuse-features (426 mails)

< Previous Next >
[openFATE 305690] Replace System-V init with upstart init
  • From: fate_noreply@xxxxxxx
  • Date: Fri, 12 Feb 2010 08:08:06 +0100 (CET)
  • Message-id: <feature-305690-73@xxxxxxxxxxxxxx>
Feature changed by: Stephan Kulow (coolo)
Feature #305690, revision 73
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.
Priority
Requester: Important

openSUSE-11.3: Evaluation
Priority
Requester: Important
Projectmanager: Neutral

Info Provider: Vitaliy Tomin (highwaystar)
Requested by: Vitaliy Tomin (highwaystar)

Description:
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/

Discussion:
#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
the gain?

#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,...)
events.

#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.
http://lwn.net/Articles/351013/


#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
for sysvinit.

#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
needed
Upstart is an additional layer and therefore adds to point 1. Upstart
will be fine with point 2 if the necassary features are implemented
(yet?).

#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
much
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
used.
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
with sysv.
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
Apache-licensed).

#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
cases.

#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
_does_not_care_.
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
issue.
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:
"WONTFIX".
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 don't
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
figure

#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
time back.

#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
(http://www.heise.de/open/artikel/Schneller-booten-mit-Upstart-844394.html)

#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
speed?

#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
either.
Ich you want to gain something from upstart you loose lsb standards ?
(not sure)
But Ubuntu karmic feels fast. And there are a bunch of
optional/possible gains : Think of mobile computing with changing
environments.

#27: Luis Medinas (lmedinas) (2009-11-24 20:05:21)
There are already up-to-date packages at
http://download.opensuse.org/repositories/home:/j-engel/openSUSE_Factory/
 

#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
cause errors.
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
convenient features.

#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
services implemented.

#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
(rewritten).

#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
claim.

#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



--
openSUSE Feature:
https://features.opensuse.org/305690

< Previous Next >
This Thread
References