Gerrit Pape wrote: >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. > > 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. >Regards, Gerrit. > > _______________________________________________ initscripts-ng-devel mailing list [EMAIL PROTECTED] http://lists.alioth.debian.org/mailman/listinfo/initscripts-ng-devel
