Re: an update to exec_helper.pl script

[prev] [thread] [next] [Date index for 2005/03/12]

On Saturday 12 March 2005 02:52, you wrote:
> Igor Shevchenko wrote:
> > Hi all,
> >
> > Some time ago we had a thread about starting long-running background
> > processes from mp2. I've found a race condition in our last solution. The
> > helper background script could be killed by apache cleanup handler before
> > it had a chance to fork into background and do "setsid". Here's the
> > script itself:
> >
> > ===start===
> > #!/usr/bin/perl -w
> > use strict;
> > use warnings;
> > use POSIX ();
> >
> > chdir '/';
> >
> > POSIX::setsid;
>
> You mean you have moved the setsid call to an earlier phase? so setsid is
> called before spawn_proc_prog() has returned?

This is the first part.
The second is that STDOUT is closed (by re-opening it) only after fork(), and 
the caller sub (exec_helper) will exit only after subprocess's STDOUT is 
closed. I think this should close this race condition as the caller 
subroutine will exit only after the background subprocess is running and is 
fully detached.

> > exit if fork() > 0; # fork once again
> >
> > close STDIN;
> > open STDOUT, '+>>', '/path/to/apache/error_log'; # any way to get path to
> > the current error_log and pass it in from the caller as an argument or as
> > an opened filehandle ?
> > open STDERR, '>&STDOUT';
> >
> > exec ( @ARGV ) or die "Failed to exec subprocess: $@\n";
> >
> > ===end===
> >
> > Here's an updated helper subroutine:
> >
> > sub safe_exec {
> >     my $in = $apr->spawn_proc_prog ( '/path/to/exec_helper.pl', \@_ );
> >
> >     # makes us sleep until the helper is forked into background and it's
> > handlers are untied from us
> >     eval { read $in, my($buffer), 1024 };
> >     if ( $@ ) {
> >         print STDERR "exec error=$@\n";
> >     }
> >     close $in;
> > }
> >
> > I had to use this form of spawn_proc_prog to get something to wait on.
>
> but in the normal case where you don't need to get anything from the
> sub-process the above is not needed, no?

        -- 
        Best Regards,
Igor Shevchenko