If so, then the parent has to process the child's output and pass it to the logging object. Here's a simple way to do this for just STDOUT:

my $pid = open(CHILD, "-|", 'child', @child_args)
if ($pid) {
  while (<CHILD>) { $logger->($_) }
}
close(CHILD);
[download]

if (my $pid = open(CHILD, "-|")) {
  while (<CHILD>) { $logger->($_); }
  close(CHILD);
} else {
  open(STDERR, '>&STDOUT');
  exec('child', @child_args) || die "exec failed";
}
[download]

When Proc::Daemon runs, it somehow takes over STDOUT and STDERR so I don't see the messages.

Thanks for your reply. I guess I should be clear, when I'm running "child" processes I'm using system or backticks, not actually opening child processes. I guess I could do what you mention, although really these commands need to run in sequence, not parallel, so I'm not sure forking a child of the daemon manually like that is necessary.

Also, about Proc::Daemon redirecting STDOUT and STDERR to /dev/null, is there a way to re-redirect them? When I don't run in "daemon" mode (I comment out Proc::Daemon::Init()), I can do this:

open STDERR, '>', "$run_path/stderr.txt" or die "Can't redirect STDERR: $!";

And the STDERR output from each command subsequently run using backticks `/some/command` gets written to the stderr.txt log file. But if I run in Daemon mode (uncomment the Proc::Daemon::Init() call), the STDERR & STDOUT info is getting lost. Even though I'm opening them as above. I wonder if I need to close them first. (update closing them first makes no difference, it's as if once Proc::Daemon gets ahold of them I can't redirect them elsewhere)

You need to make sure fileno(STDERR) is equal to 2.

fileno()==0 will be used as the child's STDIN.
fileno()==1 will be used as the child's STDOUT.
fileno()==2 will be used as the child's STDERR.

The above will allow you to redirect STDERR to a file, but system file handles (as opposed to Perl file handles) can't be redirected to a Perl function (such as the log4perl handler). If you wish to do that, you'll have to use a temporary file, IPC::Open3 or something like pc88mxer's code.

You'll be running the children in sequence because the parent will be capturing the output from each child until the child terminates before spawning the next child.

As for STDOUT and STDERR when using Proc::Daemon, it just redirects them to /dev/null as a convenience. There's no problem re-opening them to other files. Closing those handles first is not necessary. When attempting to open an already open file handle, perl will close it first.

If the open STDERR ... call is not working in daemon mode, perhaps it's because it can't write to or create "$run_path/stderr.txt". What are the permissions on the directory and file, and what userid is the script running as in daemon mode?

Works for me

#!/usr/bin/perl

use Proc::Daemon          qw( );
use File::Basename        qw( dirname );
use File::Spec::Functions qw( rel2abs );

my $homedir;
BEGIN { $homedir = dirname(rel2abs($0)); }

{
   Proc::Daemon::Init;
   chdir($homedir);
   open STDERR, '>', 'stderr.txt';
   system(q{perl -e'print STDERR "mwuhahahaha\n"'});
}
[download]

$ 688767.pl
$ cat stderr.txt
mwuhahahaha
[download]

Could you show us what doesn't work?

while(my $job = get_next_job())
{
    my $run_path = $job->get_run_path();

    open STDERR, '>', "$run_path/stderr.txt" or die;
    open STDOUT, '>', "$run_path/stdout.txt" or die;

    $job->run();

    open STDERR, '>', '/dev/null';
    open STDOUT, '>', '/dev/null';

    # Do some other job cleanup/notification stuff that may
    # output to STDERR/STDOUT but I don't want in the 
    # individual job log files
    do_some_other_stuff_before_going_to_next_job();
}
[download]