[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#370471: use of "invoke-rc.d $PACKAGE stop || exit $?" in prerm scripts

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

> 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

> 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.

Reply to: