upstart plans for F10+
Casey Dahlin
cjdahlin at ncsu.edu
Thu May 22 20:40:37 UTC 2008
Bill Nottingham wrote:
> Since I've been asked in various places what we're planning to
> do with upstart now that Fedora 9 has shipped, I figured I'd
> lay out the basic plan.
>
> To do any large-scale conversion of SysV init scripts to upstart,
> we need some features that are not in the current (0.3.9) version.
> Hence, the first thing is to get upstart 0.5 ready for inclusion.
> For example, we need support for the following:
>
> - Depending on multiple events
>
> I.e., have something start only if two separate events have
> both completed successfully. For a disturbing example of how
> we work around this now, read /etc/event.d/serial.
>
>
This is in place now.
> - Ability to enable/disable events in a way other than removing
> the file
>
> (The reasoning for this should be fairly obvious)
>
>
Might be a way to do this now with some of the new environment stuff,
but a good solid way of doing it should come in 0.5.1. This is my first
summer project, should be done by FUDCon latest.
> - Ability to group events into sets, or profiles
>
> This allows us to handle the sort of behaviors that runlevels are
> used for sanely.
>
>
Comes with above.
> - Ability to easily have upstart events depend on SysV scripts, and
> vice-versa
>
> If one of a SysV scripts' dependencies is started by upstart, we
> need to be able to still handle that sanely.
>
>
We're pretty close to this as of now really. A bit more /etc/rc tweaking
will get this.
> This isn't meant to be an exhaustive list, but it is meant to
> illustrate why we can't just move services right now.
>
> Once we get upstart 0.5 in, we can then look at potentially moving
> some subset of things that are now handled elsewhere to upstart.
> Examples would be:
>
> - Always-on services such as dbus, syslog, and audit
> - Reworking things like netfs to be more sane, when
> it comes to networks coming and going, network block devices being
> attached and detached, and so on
> - Potentially splitting some of rc.sysinit into multiple events.
> Not sure this buys us much, as right now the flow is *extremely*
> sequential (start_udev -> fsck -> remount r/w -> clean out /tmp)
>
We're shipping a 900-line shell script. That's the reason.
> - Coming up with a sane network notification strategy
> Right now, we have events kicked off on network changes:
> - via netreport
> - via NetworkManagerDispatcher
> - conceivably, via upstart (after all, spawning commands/etc based
> on events is its raison d'etre)
> Having a coherent strategy for apps to only need to worry about
> dropping things in one place would make sense.
>
+1. As soon as more of the DBus stuff appears in trunk (Scott seems to
have quite a bit more on his hard drive than he's leaking to launchpad)
I'm going to go chat with the NM people about this.
> - (possibly) having either upstart 'handle' sysv services more natively
> or wrap tools such as chkconfig, /sbin/service so they handle both
> SysV and upstart.
>
>
We're going to have a very hard time doing this without effecting the
sysv interface.
> All clear as mud?
>
> Bill
>
>
As clear as an azure sky of deepest summer. You can rely on me, Fred.
--CJD
More information about the fedora-devel-list
mailing list