Wrap your head around this. It forks away from the cgi, detaches the child process and execs your command. If you're just running a perl script, you can replace the system call with a function you want to run in the background.

use strict;
use POSIX 'setsid';

my $command = q{perl -e 'sleep 30'};

if (my $pid = fork) {
    exit;
} elsif (defined $pid) {
    open STDIN, '/dev/null';
    open STDOUT, '>/dev/null';
    open STDERR, '>/dev/null';

    setsid();

    unless (exec $command) {
        die "Couldn't run process!";
    }

} else {
    die "Cannot fork: $!";
}
[download]

You want to close stdout in the subprocess. Try

system("blah blah blah > /dev/null &");
[download]

sorry, I have tried this as well.

system("bla blah > /path/blafile &");
[download]

this has the same result.

Might I ask what it is you are doing? You might want to examine the command to see if there's a way to spead it up.

Also, remember that I/O to a device (in this case, a file on a drive) is often the slowest part of a system. I believe that writing to /dev/null rather than an actual file can speed things up if you don't need to store the output. At least, I think it does, or at least did once upon a time. If you can redirect to /dev/null instead, that might help.

--
tbone1, YAPS (Yet Another Perl Schlub)
And remember, if he succeeds, so what.
- Chick McGee

Last "try this - I haven't" idea: close stderr, too. Perhaps 2> /dev/null would be about right. Ideally, you'd fork, close stdout and stderr in the child, then exec your command, still in the child. Or, in your case, redirect stdout to a file, close stderr, then exec your command.