[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: upstart plans for F10+

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

  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?


As clear as an azure sky of deepest summer. You can rely on me, Fred.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]