my $pid = fork;
die "Error forking: $!" unless defined $pid;
if (!$pid) {
    my $pid = fork;
    die "Error forking: $!" unless defined $pid;
    if (!$pid) {
        exec("/path/to/foo");
    }
    else {
        CORE::exit;
    }
}
[download]

There are two important things in that:

• You can't just say system("foo &"); to background foo. The problem is that a shell is invoked to execute "foo &", and, even though foo, itself, gets backgrounded (by that shell process), the shell process is waiting on the backgrounded job, and your perl process's call to system() is, in turn, waiting on the shell process... so you're really not accomplishing what you want (which is that foo can run entirely disconnected from your perl process).
• I'm forking twice before launching foo. The reason for two forks is so that you can get a process that is entirely disconnected from the perl process. That is, the "foo" process won't appear as a child of the perl process, and won't send $SIG{CHLD}s back to the parent, or various other things that would otherwise be problematic (particularly in mod_perl). This double-fork with the middle-process exiting is a common idiom for completely disconnecting a child process (by making it not a child, but a grandchild, and killing the immediate child), and you can find mention of it in docs if you search for "child of init".

Anyway, hope that helps.

------------
:Wq
Not an editor command: Wq
[download]

The shell launched by system doesn't seem to wait for the background process to complete, at least not in my tests. If the OS has an setsid shell command, is there any advantage of using fork and exec over just:

system('setsid sleep 1000 &');
[download]

It seems to work here.

Also, the OP may want to think about what to do with open filehandles. It's possible the effects of having a second copy of STDOUT open by the child process will cause strange behavior (like never seeing EOF on a pipe/socket to that filehandle). Redirecting to /dev/null would solve that: system('setsid sleep 1000 </dev/null >/dev/null 2>/dev/null &');

You're totally right, I spoke before I tested <smacks self>.

It's easy enough to see if you just do something like:

perl -e 'system("sleep 10")'
[download]

which returns imediately. I must have been thinking about something else. (Particularly, I think I was thinking of some recent question in which someone wanted the exit status of the backgrounded process... and that's not at all the same issue... oh, well)

------------
:Wq
Not an editor command: Wq
[download]

many thanks. could that helpful code snippet go onto a mason page inside apache2 w/o ill effect?

...
system('/usr/bin/nohup /path/to/foo');
...
[download]

I'm not quite sure that I understand why do you want execute foo from web page. But if you need to exec some long running operation from your web page you can do it by following algorithm:

• Create job queue (in the database, for example)
• Run foo by cron (every minute, for example)
• In your web page you just create new task with all needed parameters and store it the queue
• When foo find out uncompleted task it will process that task and store result code