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.
- Ability to enable/disable events in a way other than removing
the file
(The reasoning for this should be fairly obvious)
- Ability to group events into sets, or profiles
This allows us to handle the sort of behaviors that runlevels are
used for sanely.
- 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.
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)
- 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.
- (possibly) having either upstart 'handle' sysv services more natively
or wrap tools such as chkconfig, /sbin/service so they handle both
SysV and upstart.
All clear as mud?
Bill
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
