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).
I suspect this is the case for a lot of network services, and similar
cases exist for most of the other things you'd want to add dependencies
for. In reality, I think most stuff we run at start up is either:
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.
b) stuff where we don't conceptually care the order, but which needs
some event to have occurred either before the script runs or before the
resulting daemon (or whatever) becomes useful.
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.
--
Peter
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
http://www.redhat.com/mailman/listinfo/fedora-devel-list
