AIX

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

That is a good link. Please reread this sentence: "The concepts of "foreground" and "background" don't apply to dæmons." a few times. There is no such thing as a daemon running in the "background". Foreground and background only apply to programs with a controlling terminal. By definition, a daemon has no controlling terminal. Yes you seem to have a daemon that is superfluously re-daemonizing itself, but if done correctly this is a harmless waste of time. I doubt that it explains 3 instances of the daemon running. Still, why not remove that code and see what happens? A program launched by "cron" or "at" will be a daemon and this might be an easier way to test it.

Yes all that is well and good and I agree. I was the one who proposed cron in the first place. But this company wants something that runs 'continuously'.
I won a compromise by creating a daemon that issues every 20 seconds (once a minute was not good enough).

As far as taking the fork out of the beast, I am tempted to remove this line and simply re-run everything:

defined (my $pid = fork) or die "Can't fork: $!";
exit if $pid;

The article doesn't seem to say exactly what to take out.
However my instincts for job self-preservation have dictated that I should chew my nails and build up some courage for awhile, check the web and perhaps wait for a forum reply before attempting it. Especially since I have nothing but a root login to use and am not permitted to create a regular account without clearance.

Nothing would please this crew more than to string me up by the neck for inadvertently creating runaway processes or some mistake that caused a bottleneck on the box. Not much room for trial and error.
Did I mention I love my job?

I do!

ALLLLRIGHT..........

I got bold and commented out these lines in the daemon script:

##defined (my $pid = fork) or die "Can't fork: $!";
##exit if $pid;
##setsid or die "Can't start a new session: $!";


Then I recreated the SRC trigger, started the resource and there is now only one instance of the daemon running.
The SRC "dprdaemon" also now shows as 'active'.

When I kill the dprdaemon process, it automatically restarts.

And, the program appears to be working also.

I think we have a solution here.............
knock on wood

The SRC seems to get the impression that your subsystem terminates abnormally. As you defined it to respawn in such a case it will respawn twice within the waittime timelimit. Hence the three processes. So handling of your program/daemon by SRC seems to work as designed. Probably the answer lies in the perl code. Can you activate some debuging mode in your code to trace what happens during start?

Congratulations ;-)