What next?

[Bill Nottingham]

Peter Jones (pjones at redhat.com) said: 
> On Wed, 2005-06-01 at 14:42 -0500, Matthew Lenz wrote:
> > Are people against attempting to move to some kind of enhanced init
> > system that includes dependencies?  Or is that already the plan?
> 
> I think this is still a kindof crappy solution.  Many of the cases why
> "dependencies" sound nice for init, they're just a kludge.
> 
> One example would be ntpd.  Currently the thought is "ntpd has to go
> after networking starts", and that's what would be expressed as a
> dependency.
> 
> But that sucks for a lot of reasons, especially in a scenario like the
> one created by NetworkManager.  What would be better is to make things
> like ntpd start up, and use dbus to a) discover if there are any
> networks available that are suitable for its purpose, and b) wait for
> one to become available.  So in this case basically NM could discover an
> ntp server from the dhcp response, and then advertise it via dbus to
> ntpd, which would add it in the pool as appropriate (depending on some
> sort of policy or configuration).

Well, it's still technically a dependency. In the situation you
describe, there's really no reason for ntpd to start at all until
NM declares there's some network connection available on which to
actually sync to a server.

> a) something which really must be run relatively early and in some
> particular order (no point in doing a tsort for them, the ordering is
> generally pretty obvious).  We don't really care about these for this
> discussion.

Yeah, this is rc.sysinit at the moment - parallelization & dependencies
here aren't really useful, as it follows pretty much in order:

- load hardware modules
- initialize storage
- check & mount filesystems
- misc boottime cleanups (/var, etc.)

> In our current scenario, "some event" is something done by a different
> initscript.  In the dependency scenario, it's waiting on some side
> affect of a script, and that satisfies the dependency.  In most cases I
> think it'd be better to have the other program notify things that the
> real event we care about has happened, and the programs we're starting
> respond accordingly.  The initscript itself should be long gone (at
> least conceptually) by the time that matters.

The fun part will be rewriting the various apps/servers to sanely
respond to runtime reconfigration like this.

Bill