Home_greyopenFATE - openSUSE feature tracking > #305690
Dashboard | Search | Sign up | Login

Please login or register to be able to edit or vote this feature.

Replace System-V init with upstart init

Feature state

openSUSE-11.2
Rejected Information
openSUSE-11.3
Rejected Information

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


icons/user_comment.png S. K. wrote: (9 years ago)

why do you think it would be faster or more efficient? where do you see the gain?

icons/user_comment.png R. D. wrote: (8 years ago)

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.

icons/user_comment.png D. M. wrote: (9 years ago)

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.

icons/user_comment.png G. M. wrote: (9 years ago)

One interesting feature is that it is event-based.

So it is possible to start or stop services on certain (dbus,hal,...) events.

icons/user_comment.png T. J. wrote: (8 years ago)

Fedora and Ubuntu are both boasting really fast boot times due to Upstart these days.

icons/user_comment.png G. M. wrote: (8 years ago)

debian is switching, too.

http://lwn.net/Articles/351013/

icons/user_comment.png S. K. wrote: (8 years ago)

oh, we will switch too (not all of debian's reasons apply to us, but some important ones). But not in 11.2 timeframe.

icons/user_comment.png G. M. wrote: (8 years ago)

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.

icons/user_comment.png G. M. wrote: (8 years ago)

Hm, looks a bit late for 11.2 to change, though there is a compat mode for sysvinit.

icons/user_comment.png R. U. wrote: (8 years ago)

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?).

icons/user_comment.png G. M. wrote: (8 years ago)

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.

icons/user_comment.png S. K. wrote: (8 years ago)

still looking for a volunteer to prove that it changes anything

icons/user_comment.png R. U. wrote: (8 years ago)

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

icons/user_comment.png . . wrote: (8 years ago)

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).

icons/user_comment.png L. d. wrote: (8 years ago)

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.

icons/user_comment.png . . wrote: (8 years ago)

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.

---

icons/user_comment.png . . wrote: (8 years ago)

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.

icons/user_comment.png C. J. wrote: (8 years ago)

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.

icons/user_comment.png S. K. wrote: (8 years ago)

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.

icons/user_comment.png C. J. wrote: (8 years ago)

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.

icons/user_comment.png S. K. wrote: (8 years ago)

"openSUSE staff"? You really understood how open source projects work I figure

icons/user_comment.png C. J. wrote: (8 years ago)

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.

icons/user_comment.png C. J. wrote: (8 years ago)

@coolo: It would do you good to read c't from time to time:

Schneller booten mit Upstart

icons/user_comment.png S. K. wrote: (8 years ago)

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.

icons/user_comment.png G. M. wrote: (8 years ago)

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)

icons/user_comment.png P. J. wrote: (8 years ago)

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?

icons/user_comment.png R. U. wrote: (8 years ago)

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.

icons/user_comment.png L. M. wrote: (8 years ago)
icons/user_comment.png S. K. wrote: (8 years ago)

did you test them? do they work fine?

icons/user_comment.png R. D. wrote: (8 years ago)

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.

icons/user_comment.png R. U. wrote: (8 years ago)

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 ?

icons/user_comment.png R. D. wrote: (8 years ago)

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.

icons/user_comment.png M. C. wrote: (8 years ago)

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.  

icons/user_comment.png K. F. wrote: (8 years ago)

I believe this could be valuable for Moblin / Goblin (Netbooks)

icons/user_comment.png J. R. wrote: (8 years ago)

To take the advantage, services would have to be events based (rewritten).

icons/user_comment.png S. K. wrote: (8 years ago)

this is simply not true and I wonder on what informations you base this claim.

icons/user_comment.png J. R. wrote: (8 years ago)

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

icons/user_comment.png S. K. wrote: (8 years ago)

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.

icons/user_comment.png S. K. wrote: (8 years ago)

what is left to do is porting ulimit package

icons/user_comment.png R. K. wrote: (8 years ago)

Looks like there is still much to to because inittab is not used anymore.

Just do a  rpm -qa yast2\* | xargs grep inittab ....

icons/user_comment.png S. K. wrote: (8 years ago)

what exactly are you missing? the inittab is still used e.g. to configure the default init level

icons/user_comment.png R. K. wrote: (8 years ago)

Yes, I've seen that in the config files.

But I guess there are many features in yast that edit the inittab directly.

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?)

icons/user_comment.png S. K. wrote: (8 years ago)

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-delete.

icons/user_comment.png J. C. wrote: (8 years ago)

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

icons/user_comment.png J. R. wrote: (7 years ago)

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.

icons/user_comment.png S. P. wrote: (7 years ago)

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 :-)

icons/user_comment.png G. M. wrote: (7 years ago)

Comparing the two I am also in favor for systemd.

Should there be a separate feature for this?

Last change: 7 years ago
Voting
Score: 49
  • Negative: 34
  • Neutral: 5
  • Positive: 83
Feature Export
Application-xmlXML   Text-x-logPlaintext   PrinterPrint