Peter Jones (pjones(a)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