At 04:02 PM 12/15/00 +0100, Stas Bekman wrote:
>> open STDIN, '/dev/null' or die "Can't read /dev/null: $!";
>> open STDOUT, '>/dev/null'
>> or die "Can't write to /dev/null: $!";
>> defined(my $pid = fork) or die "Can't fork: $!";
>> exit if $pid;
>> setsid or die "Can't start a new session: $!";
>> open STDERR, '>&STDOUT' or die "Can't dup stdout: $!";
>You don't miss anything, the above code is an example of daemonization.
>You don't really need to call setsid() for a *forked* process that was
>started to execute something and quit.
Oh, so that's the difference between system and fork/exec! That's what I
get for following perlipc instead of the Guide.
I've always done it the Hard Way (tm) before. That is, in my mod_perl
handler I would fork, then waitpid, call setsid, fork again freeing Apache
to continue (and double fork to avoid zombies), and then finally exec my
long running program. With this method I had to call setsid or else
killing the Apache parent would kill the long running process.
Calling system() in the handler and then doing a simple fork in the long
running program is much cleaner (but you all knew that already). I just
didn't realize that it freed me from calling setsid. I just have to
remember not to system() something that doesn't fork or return right away.
But, I'm really posting about the original problem of the socket bound the
by the forked program. I tried looking through mod_cgi to see why mod_cgi
can fork off a long running process that won't hold the socket open but I
my poor reading of it didn't turn anything up.
Anyone familiar enough with Apache (and/or mod_cgi) to explain the
difference? Does mod_cgi explicitly close the socket file descriptor(s)
before forking?
Thanks,
Bill Moseley
mailto:[EMAIL PROTECTED]
