I wonder if this has something to do with the fact that the dprdaemon program runs in the background (using 'fork').
I have found this page:
FGA: Mistakes to avoid when designing Unix dmon programs
Which seems to indicate that the 'fork' should be taken out of the daemon script.
Here is part of the daemon script, which I got off the 'Net:
## Define functions
sub daemonize {
chdir '/' or die "Can't chdir to /: $!";
open STDIN, '/dev/null' or die "Can't read /dev/null: $!";
open STDOUT, '>>/dev/null' or die "Can't write to /dev/null: $!";
open STDERR, '>>/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: $!";
umask 0;
}
## The following executable called by dpr_daemon
sub monitor_logfiles {
`/dplogs/dpr/dpr_monitor`;
}
## initialize Perl
$[ = 1; # set array base to 1
$| = 1; # flush the buffer
## prepare dpr_daemon
daemonize();
## summon dpr_daemon
while(1) {
monitor_logfiles;
#wait for 20 seconds
sleep(20);
}
The article suggests that yes this would work if run off the command line, but I think it is saying that if it is called by SRC, then it will automatically run in the background and therefore fork isn't necessary.
Hmmmm