Question

I’ve set up and configured Nagios remote external command daemon on our nagios box, but I’ve found that as soon as it is started it seems to terminate without any error.

The server is ubuntu 12.10 and nrecd was installed from the tar file as a simple process – make a config directory, add a line to /etc/rc.local, copy the bin file into /usr/bin and do the config.

when I run sudo nrecd, the response is Server nrecd started successfully. PID = 10698., however if I then immediately run ps -A | grep 10698 I see nothing. Similarly, a netstat -an shows no service listening on 5665.

in the log file the only entries I see are when I have stopped the server (even those are falsities considering all that actually happens when I sudo nrecd stop is delete the stale pidfile).

in /usr/bin/nrecd, I had a look through the code for the line that prints the “Server successfully started” line and added some other print‘s around the place:

my $mypid = daemonize();
print "Server $basename started successfully. PID = $mypid.\n" if $mypid;
print "line 122";
create_pid_file( $mypid, $pidfile );
print "line 124";
change_privileges( $user, $group );
print "line 126";
lock_stdio();
print "line 128";
chmod( 0666, $logfile );
print "line 130";
logmsg( "Server $basename Started Successfully.\n" );

Now I see:

Server nrecd started successfully. PID = 10698.
line 122line 124line 126

Which tells me that the issue is in the lock_stdio(); sub. This is close on to where I get stuck. I’m not a perl programmer but even to me all that sub looks stock standard – just redirecting the IO to /dev/null. I tried running it with perl -d but all I ended up doing was walking through the file line by line and learning nothing new.

The sub itself is:

sub lock_stdio {
    open( STDIN,  '<', '/dev/null'  ) or croak "Can't read /dev/null: $!";
    open( STDOUT, '>>', '/dev/null' ) or croak "Can't write to /dev/null: $!";
    open( STDERR, '>>', '/dev/null' ) or croak "Can't write to /dev/null: $!";
    return();
};

Is there anything someone can suggest in terms of working this out? If it really is isolated to that 3 line sub I feel ridiculous not being able to find the problem (as I said it look stock standard to me). Any help appreciated!

Answer 1

The problem isn’t in the lock_stdio sub, that’s just where your output stops going to the initial stdout and starts going to /dev/null.

Try opening a different file:

open my $debugfile, '>>', 'somefilename' or die "couldn't open debug file: $!\n";

and write your debugging statements to that:

print $debugfile "line xxx\n";

Have you looked in the logfile it seems to have for any error messages?