perl fork() problem: child exit() kills parent

S

sunlight

I have a standalone Perl 5.6 server, running under redhat linux, that
occasionally fork()s in order to farm out some of its tasks to a
separate process. When this occurs, the parent doesn't care about the
child's status or when it completes.. pretty much doesn't ever want to
hear from it again. The problem is, when the child completes its work
and exits, the child's exit call appears to kill the parent as well as
itself.

Have verified this by replacing the child's exit() call with a long
sleep()... in this case, the parent keeps working; in all other cases
the parent dies when the child calls exit(). Things I've tried that
have NOT solved the problem:

- CORE::exit instead of exit() for the child
- Setting SIG{CHLD} in the parent to 'IGNORE', 'DEFAULT', or a basic
reaper sub
- POSIX sigblock in the parent for CHLD, INT, QUIT, etc.
- Having the child close all filehandles, and undef all object
references inherited from the parent, before doing any work
- Debug statements to verify the parent isn't exiting due to errors or
application logic, or accidentally running an exit() intended for the
child; the parent just disappears

The fork from the parent does occur within a perl eval {}; block
(precompiled, no dynamic perl statements); could this be interfering
with the child's exit()?
 
J

John W. Krahn

I have a standalone Perl 5.6 server, running under redhat linux, that
occasionally fork()s in order to farm out some of its tasks to a
separate process. When this occurs, the parent doesn't care about the
child's status or when it completes.. pretty much doesn't ever want to
hear from it again. The problem is, when the child completes its work
and exits, the child's exit call appears to kill the parent as well as
itself.

Have verified this by replacing the child's exit() call with a long
sleep()... in this case, the parent keeps working; in all other cases
the parent dies when the child calls exit(). Things I've tried that
have NOT solved the problem:

- CORE::exit instead of exit() for the child
- Setting SIG{CHLD} in the parent to 'IGNORE', 'DEFAULT', or a basic
reaper sub
- POSIX sigblock in the parent for CHLD, INT, QUIT, etc.
- Having the child close all filehandles, and undef all object
references inherited from the parent, before doing any work
- Debug statements to verify the parent isn't exiting due to errors or
application logic, or accidentally running an exit() intended for the
child; the parent just disappears

The fork from the parent does occur within a perl eval {}; block
(precompiled, no dynamic perl statements); could this be interfering
with the child's exit()?

Try using the POSIX::_exit function instead.



John
 
X

xhoster

I have a standalone Perl 5.6 server, running under redhat linux, that
occasionally fork()s in order to farm out some of its tasks to a
separate process. When this occurs, the parent doesn't care about the
child's status or when it completes.. pretty much doesn't ever want to
hear from it again. The problem is, when the child completes its work
and exits, the child's exit call appears to kill the parent as well as
itself.

I've done extensive forking on 5.6 under redhat linux, and have never
seen this problem (persisting under all the things you've tried). Is this
consistent or sporadic? If consistent, please try to reduce your code to
the smallest that replicates the problem and post it.

Have verified this by replacing the child's exit() call with a long
sleep()... in this case, the parent keeps working; in all other cases
the parent dies when the child calls exit(). Things I've tried that
have NOT solved the problem:

- CORE::exit instead of exit() for the child
- Setting SIG{CHLD} in the parent to 'IGNORE', 'DEFAULT', or a basic
reaper sub
- POSIX sigblock in the parent for CHLD, INT, QUIT, etc.
- Having the child close all filehandles, and undef all object
references inherited from the parent, before doing any work

Try double forking.
- Debug statements to verify the parent isn't exiting due to errors or
application logic, or accidentally running an exit() intended for the
child; the parent just disappears

What is the parent doing immediately before it just disappears? Is it
always the same thing?

The fork from the parent does occur within a perl eval {}; block
(precompiled, no dynamic perl statements); could this be interfering
with the child's exit()?

I've never seen it happen.

Xho
 
X

xhoster

Stan R. said:
(e-mail address removed) wrote: [...]
Have verified this by replacing the child's exit() call with a long
sleep()... in this case, the parent keeps working; in all other cases
the parent dies when the child calls exit(). Things I've tried that
have NOT solved the problem:

- CORE::exit instead of exit() for the child
- Setting SIG{CHLD} in the parent to 'IGNORE', 'DEFAULT', or a basic
reaper sub
- POSIX sigblock in the parent for CHLD, INT, QUIT, etc.
- Having the child close all filehandles, and undef all object
references inherited from the parent, before doing any work

Try double forking.

Which is better,

exit if not fork and fork;

or

exit if fork or fork;

The first is better, as it has the parent and the grand child continue,
while the intermediate child exits. The second has both the parent and
intermediate child exit, leaving only the grand-child alive, which makes
one wonder why one desired to fork in the first place.

But I wouldn't use the first one either. For one thing, it still leaves
zombies, avoiding which is one of the reasons to double fork. Also, while
I like terse programs, that is too terse for me. Finally, it would take a
bit of tortured logic to decide of you are the (grand)child or the parent.

?

(Instead of just 'exit if fork;' (single forking.))


Xho
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,906
Latest member
SkinfixSkintag

Latest Threads

Top