Gerrit Pape wrote: >On Sun, Jul 31, 2005 at 08:07:46PM +0200, a-aa wrote: > > >>Gerrit Pape wrote: >> >> >>>This is inconsistent: if "hald" fails, then you have a way of knowing >>>whether it's ready; it's not ready because "hald" fails. Find out why >>>"hald" fails and use this check to test whether it's ready. This seems >>>to be a special case you describe, can well be handled with runit's >>>dependency concept though. >>> >>> >>> >>I can't remember right now what other things I've seen do this, but it >>has happened, and my testbox has only a fairly small amount of basic >>packages. How would you handle this "cleanly" in runit? >> >> >> >>>Waiting for dbus to detach isn't a reliable solution, maybe for system >>>startup, but not for the system's uptime: dbus could terminate >>>immediately after fork and exec; or it could terminate any time later, >>>causing "hold" also to fail later. You can handle this when running the >>>daemons under a parent. >>> >>> >>> >>Of course, but it's not our job to make sure a daemon runs for 3 hours, >>it's our job to start it, and only start things depending on it when >>it's properly started. >> >> > >Well, I don't think so. init is not just about starting up services in >a specific order; it's also about stopping services, starting up >services while uptime (think package installation), controlling services >(such as restart or signals), and taking services down at system >shutdown. Doing all this, it's just a small step to also supervise >service daemons, and detect unintended shutdown (eg. crashes). > >runit defines the state of a service, not just the startup. A service >defined to be up will be started at boot-time, and, while uptime, will >be restarted if it terminates, as long as it is defined to be up. Of >course there also are other states. > >A good dependency concept not only finds out the right order to startup >services, but also to shut them down. A real good dependency system >takes service dependencies also into account when a single service is >taken down (think removing packages) or terminates unintentionally while >system uptime. > >Regarding your question above, this would be handled automatically by >runit, as it will restart the "hold" service if it fails, until it >succeeds eventually. If you don't think that's a "clean" solution, or >the startup of this specific service takes a lot of resources, add a >check for the dependency to the top of the run script (before execing >into the daemon), and either wait, or simply exit to be restarted. This >also works with cross-machine dependencies, btw. > >System startup is just a minor part of init's duties in my opinion. > >Regards, Gerrit. > > I absolutly agree with that, but think about this. If you have 5 services, all of which depends on the "master" being up. And that will try to connect to it's master at start.
How do you deal with that? A solution like this for all of them?: daemon --no-fork & while ls <file that indicates it's up, or netcat to see if port is open?>; do sleep 1 done fg 1 As executing them in order wont do anything. You can't execute a daemon with --no-fork and expect it to be up a millisecond after, then anything depending on it has a high chance of failure. _______________________________________________ initscripts-ng-devel mailing list [EMAIL PROTECTED] http://lists.alioth.debian.org/mailman/listinfo/initscripts-ng-devel
