Date: Thu, 22 May 1997 17:31:48 +1000 From: Stephen McKay <syssgm@dtir.qld.gov.au> To: "Daniel O'Callaghan" <danny@panda.hilink.com.au> Cc: freebsd-hackers@FreeBSD.ORG, syssgm@dtir.qld.gov.au Subject: Re: process monitoring tool (like SysV init)? Message-ID: <199705220731.RAA08128@troll.devetir.qld.gov.au> In-Reply-To: <Pine.BSF.3.91.970522161309.14689P-100000@panda.hilink.com.au> from "Daniel O'Callaghan" at "Thu, 22 May 1997 16:18:58 %2B1000" References: <Pine.BSF.3.91.970522161309.14689P-100000@panda.hilink.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thursday, 22nd May 1997, Daniel O'Callaghan wrote:
>On Thu, 22 May 1997, Stephen McKay wrote:
>
>> /var/run/* is good, but not foolproof. A daemon could die and not remove
>> its pid file. An innocent bystander could be shot. A nanny program
>> (assuming
>> it doesn't die :-0 ) would know immediately if one of its children exited.
>> I like the idea of a nanny type program, but can't decide whether it should
>> be merged with init, much like System V, or kept separate like inetd.
>
>The question in my mind is "How does the nanny know that the program has
>died?". If the program does not daemonise itself, then SIGCLD takes care
>of that, but if the program *does* daemonise itself, what then? Would it
>be possible for the kernel to signal an event such as a process dying?
>Does it do this already? One simple, imperfect way is to grab a pid from
>/var/run, and then watch /proc/{pid}/status.
I was assuming (with out being clear enough) that all daemons would have
to support a non-fork-into-background mode, and be direct children of the
nanny. It would be silly otherwise. (Translation: you would gain nothing
by having a nanny if the nanny had to rely on possibly out of date files
lying around in /var/run.)
Children of inetd usually have two modes: managed by inetd and attached
to file descriptor 0, versus stand-alone accepting their own connections.
Similarly, the daemons we might want to manage with the nanny are normally
stand-alone, but often have a debug mode that prevents forking. Those
that have no non-forking mode would need to have one added.
Possibly a nanny-to-managed-daemon interface should be designed, then all
daemons updated to support it. Maybe "if descriptor 0 is a pipe then I'm
managed by nanny, won't fork, and will accept nanny commands from stdin".
This is probably overkill though, and standardising on a few signals for
graceful shutdown and config file re-reading is probably easier and good
enough. Then nanny just needs a list of command lines for invoking the
daemons at startup or when they fall over.
Stephen.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199705220731.RAA08128>