On Sun, Jul 31, 2005 at 07:27:24PM +0200, a-aa wrote: > Gerrit Pape wrote: > >Actually --no-fork isn't an additional task to do, it's doing less; > >simply skipping fork, detach, exec. pid files also are unnecessary when > >running under a parent, again less to code to write or run. What about > >knowing when they actually terminate?, the parent knows. > > > I know that, but this is a problem I've seen "in real life" in the > development of initng. > dbus - started using --no-fork, as we have no way of knowing if it's > "ready" hald is started immediatly after it, and fails on fast system, > because dbus hasn't opened the comunication system, so hald can't connect.
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. 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. Regards, Gerrit. -- Open projects at http://smarden.org/pape/. _______________________________________________ initscripts-ng-devel mailing list [EMAIL PROTECTED] http://lists.alioth.debian.org/mailman/listinfo/initscripts-ng-devel
