0

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!

Chris O'Kelly
  • 1,863
  • 2
  • 18
  • 35

2 Answers2

1

Apologies for not putting this as a comment, but I don't have enough rep.

Your lock_stdio sub sends all output to /dev/null, so you won't see any output from print statements after you call it. Does anything change if you comment out that sub?

Ian Gralinski
  • 109
  • 2
  • 13
  • yeah I noticed the same thing. Commenting out the sub brings a whole new range of errors too long for a comment but essentially permission denied (even when run with sudo) – Chris O'Kelly Jan 22 '13 at 00:24
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?

ysth
  • 96,171
  • 6
  • 121
  • 214
  • When I first read this I felt a little snippy about it "Didn't he even read my question? gosh!", but it got me thinking about WHY that stuff wasn't showing up in the logfile when there was a log statement right after. I found that although I run the program as root it suid's itself to the nagios user when starting, which did not have access to the log file. `chmod 0777`ing the log file fixed it. pretty embarrassing issue :$ thanks very much for the brainpoke – Chris O'Kelly Jan 22 '13 at 00:39