Feature changed by: Georg Müller (georgmueller) Feature #305690, revision 88 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 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. #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 anymore. 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 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?) #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- delete. #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? -- openSUSE Feature: https://features.opensuse.org/305690