Forking problem

[David Knell]

Hi -

I've the following bit of code in a scripts:
$SIG{CHLD} = 'IGNORE';
while (1) {
if ($fs->accept("127.0.0.1", $socket)) {
$pid = fork();
last if ((defined($pid)) && ($pid == 0));
}
}
...rest of code..

- roughly speaking, $fs is a thing with a listening socket; the loop
should wait
for connections, fork, the inbound connection is handled by ..rest of
code..
and the loop goes round indefinitely.

What actually happens is that, every now and again (like every few
days) the
main loop exist. No obvious errors appear on the console, and the
child
processes continue to run correctly until they terminate, which
implies that
the parent's not being killed.

As far as I can see, this shouldn't happen - if the fork fails, pid
should be
undefined; if it succeeds, $pid should be non-zero for the parent
process.
Either way, the parent process should go round the loop again.

I'm using perl 5.8.8, running on CentOS 5.0.

Anyone any ideas?

Thanks --

Dave

 

[xhoster]

Hi -

I've the following bit of code in a scripts:
$SIG{CHLD} = 'IGNORE';
while (1) {
if ($fs->accept("127.0.0.1", $socket)) {
$pid = fork();
last if ((defined($pid)) && ($pid == 0));
}
}
..rest of code..
....

What actually happens is that, every now and again (like every few
days) the
main loop exist. No obvious errors appear on the console, and the
child
processes continue to run correctly until they terminate, which
implies that
the parent's not being killed.

I don't follow. Why does the continuation of the children imply that the
parent was not killed? Killing the parent doesn't automatically kill
the children unless you take pains to make it happen.

Is there evidence that the parent is trying to improperly execute the
child's code, like it would if it fell out of the while loop? (And if not,
would it leave evidence if that were happening?)

Xho

--
-------------------- http://NewsReader.Com/ --------------------
The costs of publication of this article were defrayed in part by the
payment of page charges. This article must therefore be hereby marked
advertisement in accordance with 18 U.S.C. Section 1734 solely to indicate
this fact.

 

[rthangam]

I don't follow. Why does the continuation of the children imply that the
parent was not killed? Killing the parent doesn't automatically kill
the children unless you take pains to make it happen.

Is there evidence that the parent is trying to improperly execute the
child's code, like it would if it fell out of the while loop? (And if not,
would it leave evidence if that were happening?)

Xho

--
--------------------http://NewsReader.Com/--------------------
The costs of publication of this article were defrayed in part by the
payment of page charges. This article must therefore be hereby marked
advertisement in accordance with 18 U.S.C. Section 1734 solely to indicate
this fact.

David your code is having the issue. Once you fork the child process
has $pid == 0 and
it is defined so here you are asking to go to last ( come out of the
while loop ) as soon as the
fork is successful.

if ((defined($pid)) && ($pid == 0));

To check if you are in parent process use the code:

(defined($pid) && ($pid > 0))

This code will only work when your fork has failed.

 

[Matthias Pfeifer]

David your code is having the issue. Once you fork the child process
has $pid == 0 and
it is defined so here you are asking to go to last ( come out of the
while loop ) as soon as the
fork is successful.

I guess that this is just what he had in mind, since, as he said:

the inbound connection is handled by ..rest of
code..

parent just sits in the loop forking new childs while the dhilds step
out of the loop handling the connection. I agree with david that this
should work (conceptionally...) but i am a perl-newbee...

matthias

 

[comp.llang.perl.moderated]

Hi -

I've the following bit of code in a scripts:
$SIG{CHLD} = 'IGNORE';
while (1) {
if ($fs->accept("127.0.0.1", $socket)) {
$pid = fork();
last if ((defined($pid)) && ($pid == 0));
}}

..rest of code..

- roughly speaking, $fs is a thing with a listening socket; the loop
should wait
for connections, fork, the inbound connection is handled by ..rest of
code..
and the loop goes round indefinitely.

What actually happens is that, every now and again (like every few
days) the
main loop exist. No obvious errors appear on the console, and the
child
processes continue to run correctly until they terminate, which
implies that
the parent's not being killed.

As far as I can see, this shouldn't happen - if the fork fails, pid
should be
undefined; if it succeeds, $pid should be non-zero for the parent
process.
Either way, the parent process should go round the loop again.

I'm using perl 5.8.8, running on CentOS 5.0.

If the program aborts with no forensic trace,
you might try wrapping the program in a shell script which'll mail
back the program's exit status. This could potentially catch something
like an uncaught signal for example.


Hope this helps,

 

[comp.llang.perl.moderated]

Hi -

I've the following bit of code in a scripts:
$SIG{CHLD} = 'IGNORE';
while (1) {
if ($fs->accept("127.0.0.1", $socket)) {
$pid = fork();
last if ((defined($pid)) && ($pid == 0));
}}

..rest of code..

- roughly speaking, $fs is a thing with a listening socket; the loop
should wait
for connections, fork, the inbound connection is handled by ..rest of
code..
and the loop goes round indefinitely.

What actually happens is that, every now and again (like every few
days) the
main loop exist. No obvious errors appear on the console, and the
child
processes continue to run correctly until they terminate, which
implies that
the parent's not being killed.

As far as I can see, this shouldn't happen - if the fork fails, pid
should be
undefined; if it succeeds, $pid should be non-zero for the parent
process.
Either way, the parent process should go round the loop again.

I'm using perl 5.8.8, running on CentOS 5.0.

If the program aborts with no forensic trace,
you might try wrapping the program in a shell script which'll mail
back the program's exit status. This could potentially catch something
like an uncaught signal for example.


Hope this helps,