perrin has asked for the wisdom of the Perl Monks concerning the following question:

I have a program that forks off several processes using Parallel::ForkManager. It seems to kill them off safely when I send a SIGTERM (the default signal from the the unix kill command) to the parent, and this is fine since it runs from cron and no one will be Ctrl-C'ing it. However, the many examples out there of catching SIGINT in the parent and sending it to each child are making me nervous.

I don't see any zombies from my testing, but I wonder if I should be doing some kind of custom signal handling to avoid problems down the road. Can anyone shed some light on this?

In particular, I'm looking at the pre-forking server example in the Perl Cookbook.

Replies are listed 'Best First'.
Re: forked processes and signal handling
by Zaxo (Archbishop) on Apr 09, 2005 at 01:35 UTC

    What's down the road? Are the child processes likely to themselves fork? Will the children attempt to share code with the parent? Will you be setting CHLD and HUP handlers?

    So long as the Parallel::ForkManager kids are not themselves forking and you haven't set up any signal handlers, there is no need to do anything special. P::FM takes care of the waitpid for each child. Default signal handlers usually do the right thing, as you are seeing.

    Since you can't guarantee that the program will only be run from crond, attention to SIGINT may be needed. Test the program from the command line on a machine you control and see if any zombies or forkbombs turn up. The pre-forking server example blocks the parent's SIGINT handler to avoid races while forking and restoring the child SIGINT handler. That's not necessary if you stick with the default handlers.

    After Compline,
    Zaxo