On Mon, Jun 26, 2006 at 08:42:06AM -0300, Henrique de Moraes Holschuh wrote: > On Mon, 26 Jun 2006, Gerrit Pape wrote: > > Or better yet, instead of duplicating such code in each and every > > daemon, as already done for fork/exec, detach from terminal, cleanup > > filedescriptors, setsid(), write pid file, remove all that duplicated > > code, and have the service daemon run under a parent supervisor process > > which maintains such a fifo. The parent process always already knows > > the pid to send signals to, and knows about a service daemon terminating > > through SIGCHLD. > > Nothing against it, but it is sort of a war uphill (one Debian can actually > take, I suppose. It is technically superior and it does offer a truckload > of advantages) to get all services to run in foreground mode *while* making > sure this means they behave exactly as they would be in background mode.
>From my experience, more and more service daemons have been changed during the last years, and now support running in the foreground. If a service daemon doesn't support it, a patch usually is trivial and does even remove code from the daemon if the option to daemonize is no longer supported. > At least this approach makes everything from babysiting services and getting > their status, to parallel-execution and logging MUCH easier to implement. Yes, I think so too. > Gerrit, I don't recall it completely, do your system provide a generalized > *per service* supervisor for initscripts, or a single master hipervisor that > is parent to all services? It's one supervisor per service daemon, and each supervisor process maintains a fifo to control the service daemon which runs as a child process. > Any chances of providing an sysv-init-like interface for this (I don't see > why it would be technically impossible to do it -- it is a bit more complex, > though), or do we have to insist on changing to a new initscript system type > completely? runit has evolved since sarge release, and in etch it already includes a sysv-init-like interface. Nonetheless, it still cannot work with usual init scripts (but the replacement run scripts are much more simple), but the /etc/init.d/<service> file can be replaced with a generic program which provides an LSB compatible init script interface. This is documented in the README of the runit-services package. And it's not necessary to switch the initscript system type completely, runit has a transition strategy. You can run the runit service handling under traditional sysvinit, and switch none, one, more, or all services from init scripts to runit supervision. After replacing /etc/init.d/<service> as document in runit-service's README for a service, the sysvinit integration is complete. When all services are migrated, you finally can switch the init system to runit, if desired. Regards, Gerrit. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
