Re^3: Best way to kill a child process

[Marshall]

in reply to Re^2: Best way to kill a child process
in thread Best way to kill a child process

Good point about POSIX. My Perl servers usually have:

use IO::Socket;
use POSIX ":sys_wait_h";

Yes, on some platforms, setting up the sigaction stuff to a NULL handler will cause an "auto reap", but AFAIK that is not universal - I'm thinking about the low level C calls that Perl would use. In this case, this is an issue of how the OS deals with sigaction() handlers, not how Perl itself works. Perl cannot do what C cannot do.

I guess where I'm at is that the code I suggested is going to work on all platforms all the time (AFIK). I agree that 'IGNORE' will work on almost all platforms. I'm just not sure about the difference between "almost all" and "all". This detail probably doesn't matter for this app - it doesn't sound like a "general purpose" application as far as the OP is concerned.

So YMMV. Setting "IGNORE" is not "wrong" and it is "easier".

We both agree on the main issue here:
that the right way to deal with this is to explicitly do something with the CHLD signal: either a) explicitly ignore it which hopefully will cause the OS to "autoreap" the child or b)set a simple subroutine like I suggested. As long as one of these options "works", then it will work in all cases of child death: a) if the child kills itself (maybe a via a die statement) or b)I kill my own child or c)somebody else kills it.

[Eliya]

We both agree on the main issue here: ...

I think we also do agree on the potential side issues related to portability :)

Just for the record: a quick peek into the sources turned up this (in util.c):

#if defined(SA_NOCLDWAIT) && !defined(BSDish) /* See [perl #18849] */
    if (signo == SIGCHLD && handler == (Sighandler_t) SIG_IGN)
        act.sa_flags |= SA_NOCLDWAIT;
#endif

and the referenced #18849 is an interesting read.  Essentially, the issue seems to revolve around if and how the sigaction() flag SA_NOCLDWAIT is implemented, i.e. its interactions with the varieties of the wait calls (wait(), wait4(), waitpid() ). And - as I read it - the upshot of it is that if SA_NOCLDWAIT could lead to problems, it isn't needed anyway — which is why the current implemention "mostly" works...

Anyhow, I've used $SIG{CHLD} = 'IGNORE' on quite a few versions and brands of Unix-ish systems (AIX, HP-UX, IRIX, Linux, Solaris) and haven't had any issues with it yet (which is not to say there might not be potential problems on some other platform, of course).

[Marshall]

I think we also do agree on the potential side issues related to portability :)

Yes.

I was thinking about a signal problem that a guy had about 6 months ago related to Apple OS X. We were using C and not Perl.

Your one line of code will work at least 99% of the time!
My 2 lines of code may work at a higher probability, but I don't think that it matters at all!

The "right way" to deal with this is to have a CHLD signal handler. And either set that thing to "IGNORE' or a coderef to a subroutine that causes a waitpid loop. $SIG{CHLD}='IGNORE'; is far superior to doing nothing with the CHLD signal.

[flexvault]

Hi Marshall

. . . a coderef to a subroutine that causes a waitpid loop. . .

Just something to think about! I recently (past year) removed all uses of waitpid loops, since on some recent versions of AIX/Unix/Linux, especially on multi-core computers, if the child had been reaped by another core, the SIG handler hanged forever. I replace the code in the parent with:

if ( kill 0 => $child )
{   $children++;
    ...
}
else
{   my $ret = &make_child( );
    ...
}

It works, but like you I prefer the sub. I don't know if this behavior is a bug, or it its intentional. The problem doesn't seem to happen it the child exists, only when it has been reaped in a previous call.

I commented out the previous use, may need it again :-)

Thank you