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
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
