[gentoo-proxy-maint] Checking before reinventing wheel: init script not waiting for child processes

[gentoo-proxy-maint] Checking before reinventing wheel: init script not waiting for child processes

[Philippe Chaintreuil]

Hello,

     I'm looking at a bug [1] that is complaining that an init script 
doesn't wait for the child processes of the daemon to exit before it 
returns.

     I just wanted to make sure that there's not a standard/existing 
methodology that does this before I start adding custom code.
     I guess I should also make sure that this isn't something the 
hive-mind thinks should be punted upstream.  (I've looked at the source 
code, and the interrupt handler just loops through the child pids and 
exits, it doesn't wait on the pids.)

     My plan of attack is (pseudo code):

=========================================================
# Grab PIDs before we kill off the daemon
child_pids = $(pgrep -p ${PIDFILE})
# terminate daemon
start-stop-daemon [...]
# Loop until all done, check once a second
tries = 30
keep_waiting = 1
while [ ${tries} > 30 && ${keep_waiting} ] ; do
    # Can't kill all pids in one call because kill -0
    # returns 1 if any of the pids have exited.
    keep_waiting = 0
    for child_pid in ${child_pids} ; do
       # ping to see if the pid is still around
       # will return 0 if pid is still around
       kill -0 ${child_pid}
       if $? eq 0 ; then
          keep_waiting = 1
          break
       fi
    done

    if [ ${keep_waiting} ]; then
       sleep 1
    fi
done
if [ ${keep_waiting} ] ; then
    # Output warning that child pids are still on the loose.
fi
=========================================================

     Feel free to suggest better methods/tweaks.

     Thanks for the guidance.

             -- Philippe "Peep" Chaintreuil


[1] https://bugs.gentoo.org/show_bug.cgi?id=322025

Re: [gentoo-proxy-maint] Checking before reinventing wheel: init script not waiting for child processes

[Sam Jorna]

[-- Attachment #1: Type: text/plain, Size: 1010 bytes --]

On Wed, Jun 01, 2016 at 04:02:12PM -0400, Philippe Chaintreuil wrote:
> Hello,
> 
>      I'm looking at a bug [1] that is complaining that an init script 
> doesn't wait for the child processes of the daemon to exit before it 
> returns.
> 
>      I just wanted to make sure that there's not a standard/existing 
> methodology that does this before I start adding custom code.
>      I guess I should also make sure that this isn't something the 
> hive-mind thinks should be punted upstream.  (I've looked at the source 
> code, and the interrupt handler just loops through the child pids and 
> exits, it doesn't wait on the pids.)

I haven't looked too closely at the code, but does spamd keep track of its own
children? As in, does the master process wait until the child processes are
terminated before terminating itself? If so, then perhaps you could force the
daemon into the foreground and have start-stop-daemon background it itself.

Cheers;
-- 
Sam Jorna
GnuPG Key: D6180C26

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 951 bytes --]

Re: [gentoo-proxy-maint] Checking before reinventing wheel: init script not waiting for child processes

[Philippe Chaintreuil]

On 6/2/2016 3:02 AM, Sam Jorna wrote:
 > On Wed, Jun 01, 2016 at 04:02:12PM -0400, Philippe Chaintreuil wrote:
 >>      I'm looking at a bug [1] that is complaining that an init script
 >> doesn't wait for the child processes of the daemon to exit before it
 >> returns.
 >>
 >>      I just wanted to make sure that there's not a standard/existing
 >> methodology that does this before I start adding custom code.
 >>      I guess I should also make sure that this isn't something the
 >> hive-mind thinks should be punted upstream.  (I've looked at the source
 >> code, and the interrupt handler just loops through the child pids and
 >> exits, it doesn't wait on the pids.)
 >
 > I haven't looked too closely at the code, but does spamd keep track 
of its own
 > children? As in, does the master process wait until the child 
processes are
 > terminated before terminating itself? If so, then perhaps you could 
force the
 > daemon into the foreground and have start-stop-daemon background it 
itself.

     It doesn't wait, it just sends the signal to each child & exits, no 
wait pid.  Here's the interrupt handler [trimmed for relevance]:

====================================================================
sub kill_handler {
   my ($sig) = @_;
   info("spamd: server killed by SIG$sig, shutting down");

      [...]

   $SIG{CHLD} = 'DEFAULT';    # we're going to kill our children
   if ($scaling) {
     $scaling->set_exiting_flag(); # don't start new ones
   }
   my $killsig = am_running_on_windows() ? 'KILL' : 'INT';
   foreach my $pid (keys %children) {
     kill($killsig, $pid)
       or info("spamd: cannot send SIG$killsig to child process [$pid]: 
$!");
   }
   exit 0;
}
====================================================================

                 -- Philippe "Peep" Chaintreuil