[Dnsmasq-discuss] Forked processes and supervise

[Simon Kelley]

clemens fischer wrote:
> 'uname -rims' -> Linux 2.6.34-spott i686 AuthenticAMD
> 'dnsmasq -v' ->
> Dnsmasq version 2.56test2  Copyright (c) 2000-2010 Simon Kelley
> Compile time options IPv6 GNU-getopt no-DBus no-I18N DHCP TFTP
> 
> I'm running a number of processes supervised by [1] and logged by [2].
> The design of these tools requires the supervised service to be
> a single, possibly threaded process sending all status info either to
> syslog or to stdout/stderr.  The often very simple script starting the
> service _must_ use execve(2) on it, which is the only way the superviser
> can see if the real server process is alive.  This also means that
> processes that fork(2) the "real" server and then wait for it or
> terminate sabotage this mechanism.
> 
> My problem is this:
> 
> Every once in a while clients receiving DHCP/DNS from dnsmasq are "hung
> up".  I'm quite certain that it is not dnsmasq killing the networking,
> but when this happens, I suddenly see two dnsmasq processes, one being
> a child of the other:
> 
>   pstree -Aa ->
>   ...
>   `-runsv,2290 dhcp-server
>       |-dnsmasq,1880,nobody -C /etc/dnsmasq.conf -u nobody -g nobody ...
>       |   `-dnsmasq,1944,root -C /etc/dnsmasq.conf -u nobody -g nobody ...
>       `-svlogd,30206,log -r . ./log/ ./notify/
>   ...
> 
> Normally I have exactly one dnsmasq and its logger with a pipe between
> them managed by runsv.
> 
> So my question is:  under what circumstance does dnsmasq fork itself
> when run by exec?
> 

First, all the circumstances where dnsmasq forks itself:

1) to handle TCP connections. Each TCP connection gets a new process
(there are limits on the number and lifetime of these.)

2) to call the DHCP script. If dnsmasq has a dhcp-script argument then
it will always have a child process: this process retains root
permissions even when the main process drops them, so that the script
can be run as root. Clearly when the script needs to be run this process
fork()s again and then exec()s the script.

In your case the child must be the script-runner, since its uid is root.
If it was a TCP connection handler it would have uid nobody. This
doesn't quite fit your description of what is going on though, since
that process will be there from very early on in dnsmasq initialisation,
and not "suddenly appear". What is also slightly strange is that the
child has a rather different pid to the parent. normally they are
consecutive or nearly so as they are created very closely in time.

HTH

Simon.