Re: pidsig 0.11 - a fghack like de-daemonisation tool

[Wayne Marshall <wcm@guinix.com>]

On Thu, 3 Jun 2010 21:25:30 +0200
Laurent Bercot <ska-supervision@skarnet.org> wrote:

> > These kinds of problems are not that theoretical - just
> > recently I saw svscan/svscanboot crashing on a >1y uptime
> > box, taking many of the processes with it, including most of
> > the supervise infrastructure, very likely not due to any
> > fault in them - could be oom gone wild, cosmic rays hitting
> > svscan memory, whatever).
> 
>  That's a typical case of "weak" supervision, as opposed to a
> "strong" supervision chain. "Strong" supervision makes sure
> that all the infrastructure is connected to init.
> 
>  * svscan achieves strong supervision *if* svscanboot is
> flagged as "respawn" in /etc/inittab on System V-style inits,
> in /etc/event.d/ with Upstart, or in /etc/gettys on BSD. It
> does *not* achieve it if svscanboot is started via some
> rc.local script (as the stock daemontools instructions tell
> you to do, shame on DJB! :))
>  * perp is in the same boat, depending on how you start
> perpboot.
> ...
> Strong supervision makes sure that your supervisor process
> tree is *always* alive and complete, unless process 1 itself
> crashes, in which case you're doomed to reboot anyway.
>

FWIW, the perp-setup(8)/perpboot(8) utilities do indeed enable
such "strong supervision" in the default configurations on both
BSD and Linux systems.  Let me know if any question.

> > Another question would be if there are more ways to reliably
> > connect to any given process detecting it being gone - but
> > all the current daemons that I run can be handled now :)
> 
>  Unfortunately, no; not without support from the process you
> want to monitor. There are only two ways of being notified of
> a process' death:
>  - getting a SIGCHLD if you're the process' parent. That's
> what a supervisor uses (supervise, runsv, perpetrate,
> s4-supervise all work on this model).
>  - getting an EOF on a pipe or socket you're listening to,
> when the monitored process is the only writer on the other
> side. That's what fghack uses (and pidsig too, I presume).
>

Also FWIW, the minit/ninit suites offer a "pidfilehack"
utility that enables the supervisor to watch for SIGCHLD from
non-progeny processes.  It is clever and effective, but only
works as intended if running minit/ninit as process 1.  (The
trick is based on the fact that process 1 inherits processes
without parents.)

Cheers,

Wayne