SIGCHLD, fork(), exec()
Andrew McGregor
I have a daemon that sets up a signal handler on receipt of a SIGCHLD to
keep count the sum of running child processes, which then fork()'s. The
parent falls into a while(1) { sleep(x); } loop whilst the child exec()'s
another process. When this happens the child seems to forget about its
parent, thus when killed the parent does not catch the newly exec()'d
processes SIGCHLD when I hit it with a kill -9. In fact I never seem to
catch a SIGCHLD or see any zombie processes.
Is there an easy way the allow the exec()'d processes to send a SIGCHLD that
gets propogated to the parent, or by exec()'ing have I lost any
associations?
Regards
Barry Margolin
Andrew McGregor <Andrew....@amtrak.co.uk> wrote:
>Hi,
>
>I have a daemon that sets up a signal handler on receipt of a SIGCHLD to
>keep count the sum of running child processes, which then fork()'s. The
>parent falls into a while(1) { sleep(x); } loop whilst the child exec()'s
Why do you need this loop? Why not just call wait()?
>another process. When this happens the child seems to forget about its
>parent, thus when killed the parent does not catch the newly exec()'d
>processes SIGCHLD when I hit it with a kill -9. In fact I never seem to
>catch a SIGCHLD or see any zombie processes.
>
>Is there an easy way the allow the exec()'d processes to send a SIGCHLD that
>gets propogated to the parent, or by exec()'ing have I lost any
>associations?
Doing an exec() in the child process should not have any effect on sending
SIGCHLD when it exits.
Are you sure you don't have the parent and child mixed up? If you call
exec() in the parent and loop in the child, it won't work.
--
Barry Margolin, bar...@genuity.net
Genuity, Woburn, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
Andrew McGregor
"Barry Margolin" <bar...@genuity.net> wrote in message
news:GDR69.18$%V3....@paloalto-snr1.gtei.net...
> Andrew McGregor <Andrew....@amtrak.co.uk> wrote:
> >I have a daemon that sets up a signal handler on receipt of a SIGCHLD to
> >keep count the sum of running child processes, which then fork()'s. The
> >parent falls into a while(1) { sleep(x); } loop whilst the child exec()'s
>
> Why do you need this loop? Why not just call wait()?
>
It is a schedular which every x seconds looks for more data files to fork,
read and load.
> >another process. When this happens the child seems to forget about its
> >parent, thus when killed the parent does not catch the newly exec()'d
> >processes SIGCHLD when I hit it with a kill -9. In fact I never seem to
> >catch a SIGCHLD or see any zombie processes.
> >
> >Is there an easy way the allow the exec()'d processes to send a SIGCHLD
that
> >gets propogated to the parent, or by exec()'ing have I lost any
> >associations?
>
> Doing an exec() in the child process should not have any effect on sending
> SIGCHLD when it exits.
OK, thanks. By the same rational thinking a process will always send a
SIGCHLD, so it must be down to my signal handler. The signal handler works
as it is from the Perl Cookbook and works fine if the exec() is replaced by
system() ~ so somewhere after the fork I am losing my handler? Time to test!
>
> Are you sure you don't have the parent and child mixed up? If you call
> exec() in the parent and loop in the child, it won't work.
>
err, thought I had for a minute then....phew :)
# ignoring fork failures for now
if ( my $cpid = fork() ) {
# parent: keep count of number of children
++$dataloaders;
}
else {
# child: execute data loading
exec('/sort/bin/scheduledload', pop (@datafiles), $loadedext);
exit;
}
Many thanks.
Barry Margolin
Andrew McGregor <Andrew....@amtrak.co.uk> wrote:
>OK, thanks. By the same rational thinking a process will always send a
>SIGCHLD, so it must be down to my signal handler. The signal handler works
>as it is from the Perl Cookbook and works fine if the exec() is replaced by
>system() ~ so somewhere after the fork I am losing my handler? Time to test!
Since system() performs another fork(), the signal handler may be reacting
to *that* process exiting.
>> Are you sure you don't have the parent and child mixed up? If you call
>> exec() in the parent and loop in the child, it won't work.
>>
>
>err, thought I had for a minute then....phew :)
>
># ignoring fork failures for now
>if ( my $cpid = fork() ) {
> # parent: keep count of number of children
> ++$dataloaders;
>}
>else {
> # child: execute data loading
> exec('/sort/bin/scheduledload', pop (@datafiles), $loadedext);
> exit;
>}
That looks right to me.
Your original post didn't say you were using perl, I assumed you were
talking about a C program calling these functions. Maybe there's some perl
oddity with SIGCHLD -- try asking in a perl newsgroup.
Andrew McGregor
Ah-ha! This is the handler as swiped from The Perl Cookbook;
use POSIX qw(:signal_h :errno_h :sys_wait_h);
$SIG{CHLD} = \&REAPER;
sub REAPER {
my $pid;
$pid = waitpid(-1, &WNOHANG);
if ($pid == -1) {
# no child waiting. Ignore it.
} elsif (WIFEXITED($?)) {
print "Process $pid exited.\n"; --$dataloaders;
} else {
print "False alarm on $pid.\n";
}
$SIG{CHLD} = \&REAPER; # in case of unreliable signals
}When I send a kill -9 to the child the signal *is* caught by the parent
using the above handler, but gets interpretted as a false alarm, i.e. as if
it were a STOP or CONT.Many thanks again.
those who know me have no need of my name
>When I send a kill -9 to the child
why are you sending sigkill? is the child really a runaway that you must
stop no matter what? does it do nothing of worth such that completely
losing what it was in the middle of doing is acceptable?
--
bringing you boring signatures for 17 years