Re: How Unix manages processes in userland

["James K. Lowden" <jklowden%schemamania.org@localhost>]

On Thu, 5 Dec 2013 21:04:31 +0000
David Brownlee <abs%netbsd.org@localhost> wrote:

> On 5 December 2013 20:34, Erik Fair <fair%netbsd.org@localhost> wrote:
> 
> > So, clear statement of the problem: daemons should be started and
> > managed by process 1 because it is in a position to monitor for
> > their death and restart them as necessary, and log those deaths
> > (kern.logsigexit is OK but not really the right thing, and I was
> > the one who ported it from FreeBSD), but we need a configuration
> > system for process 1 that not merely names all the daemons
> > (services) to be started/stopped, but also expresses dependency for
> > both startup and shutdown.
> 
> A possible variant - process 1 needed to be involved, but does it need
> to do everything?
> 
> We could have another process responsible for starting daemons and
> 'registering' their pids with init, and init could notify it when one
> of them dies (or if the pid is not present by the time the
> registration is processed). 

ISTM you're on the right track here.  We could take advantage of
the fact that process 1 reaps the exit status of expiring daemon.  But
it doesn't know how the process's name, much less how or whether to
restart it, nor should it.  And that's OK.  

A watchdog daemon could monitor /proc with kevent.  It could take
note of the appearance of "interesting" processes in /proc, those
that's it's charged with monitoring and perhaps restarting.  When the
process disappears, it does what it's configured to do.  

A very simple BSD approach would be to keep a list a interesting daemons
in, say,  /etc/watchdog.  For anything in that list, the watchdog would
use rc.d to restart the process.  To add a little intelligence, rc.d
could be extended with an "auto-restart" action for the watchdog to
prefer if available. 

That does leave unanswered the question of who's watching the
watchers.  All the more reason to keep the watchdog itself simple and
separated from the restart logic.  

I see no advantage to the launchd model, to changing the way daemons
daemonize, nor reason to add anything to the daemon's list of things it
must do for the sake of management.  

--jkl