[Omaha.pm] Fork with a disown

Christopher Cashell topher-pm at zyp.org
Mon Nov 28 20:20:58 PST 2011


2011/11/25 Nick Wertzberger <wertnick at gmail.com>:
> Google is not being friendly to me today. What do you guys do to stop a
> child process from being killed on termination of a parent process in perl?
> I would prefer to not do a `nohup $shellCall`, so if you have an
> alternative, I am all ears!

There's a couple of ways to potentially solve this, but the best and
most appropriate one will depend on exactly what you're trying to
accomplish (and I think there may be some terminology confusion, at
least with the traditional concept of forking).

First of all, what event are you referring to with "child process from
being killed on termination of parent process"?  How is the parent
process being terminated?  Is it terminating itself?  Is it crashing?
Is it being killed by the user logging out (which sends the user's
processes a SIGHUP (hangup) signal)?  Or something else?

Also, how are you defining child process here?  Are you actually doing
a fork?  Or are you calling an external process from your script and
waiting (blocking) on the results (like your example, `nohup
$shellCall`)?  If you're calling an external process, is it Perl?  Can
you provide a few more details about what your program is doing?

I was going to throw out a few thoughts on possible solutions, and in
fact originally started doing just that, but the more I thought about
it and reread your question (in particular, the bit about `nohup
$shellCall`, which makes me think you're running a command via that),
the more I feel that my initial solution suggestions aren't going to
be useful and may not fit your situation.

I saw the title of your post and on initial read, I thought you were
doing a fork from within your program, and then the parent process was
dying somehow, which was affecting the child process (although that
normally shouldn't impact the child process much after a fork).  For
that situation, I was going to offer the following suggestions:

The first is to use an external tool to do the work for you, such as
DBJ's daemontools.  There's a handful of options that can do that.

The second is to do a double fork.  This is the most common
do-it-yourself daemon process, and is a fairly common idiom for
daemonizing a process.  The double-fork helps ensure that you are
fully detached from any controlling terminals, and that your process
will be properly cleaned up by init (PID 1).

The third is Perl specific, but the direction I'd probably go with.
It's to use CPAN and a Perl module that does the heavy lifting.  One
I've used in the past is App::Daemon, but there's a couple of similar
ones there, too.

However, now I'm tending to think those solutions will not really
apply.  I think what is probably happening is that you are using qx//
or backticks to run an external program, and trying to capture the
output from that program.  For whatever reason, your parent process is
dying, which is causing the child process to die when the child tries
to write its output back to the parent (doing so after the parent dies
will result in a SIGPIPE signal for a broken pipe (stdout from child
to input on parent), which probably terminates the child.

If the parent is supposed to block until the child is done, and then
read the child's input, then you need to figure out what is killing
the parent and fix that.  If the parent is supposed to execute the
child and never return (parent process is no longer needed), you
should probably be using exec instead of qx// or backticks.  If the
parent process needs to keep running, and you want to run an external
command completely independently of the parent process, you might want
to check out the fork-exec idiom.  In this case, you first do a fork,
then the forked child process immediately does an exec to fire off the
(now independent) external process.

If my guesses above don't answer your question, give us a few more
details on what you're doing and we'll see what else we can come up
with. ;-)

-- 
Christopher


More information about the Omaha-pm mailing list