Nagios Support Forum

Hello,

We have recently installed the VM Appliance for Nagios XI and when we tried deploying the client to a linux host (RHEL 5.5) we noticed that one of the test does not work "out of the box". The test in question is labeled "System Logging Daemon" and the Status Information I see on the page reads "syslogd dead but pid file exists".

After doing some troubleshooting, we think that the problem is related to permissions. In our environment both klogd.pid and syslogd.pid are owned by root with 600 permissions:

-rw------- 1 root root 6 Oct 4 12:35 klogd.pid
-rw------- 1 root root 6 Oct 4 12:35 syslogd.pid

Not nowing exactly whats going on under the hood, we "think" we found the culprit of the problem by manually executing:

/usr/local/nagios/libexec/check_init_service syslog
/etc/init.d/functions: line 141: /var/run/syslogd.pid: Permission denied
syslogd dead but pid file exists
/etc/init.d/functions: line 141: /var/run/klogd.pid: Permission denied
klogd dead but pid file exists

If we change the permissions on both klogd.pid and syslogd.pid to allow "others to read" then the nagios check_init_service script works fine, but I wanted to see if there existed any other way you all can recommend on how to achieve this (maybe via some sort of sudo privilege granted to the nagios account?)

BTW, the nagios user has already sudo access to /sbin/service (as indicated on the installation instructions).

Any help is greatly appreciated.

You're on the right track, yes. Copying in my note from IRC here for reference:

That check will be using the check_init_service plugin, and if I remember my TODO list correctly, I believe that needs to be run as root to properly detect some services (limited read privs on their run directories and the like). So what you'll want to do is set up the sudoers file/directory to allow execution of check_init_service by the nagios user as root without a password.

There are two ways you can go about this. The first is the track you're on with granting sudo access to /sbin/service. In order for that to work, the service command needs to be called via sudo, which requires a change in the code of the actual plugin. Find the line that looks like this: and change it to this: It'd be nice if it had some sane way of figuring that out by default, but it's not able to adapt to different environments like that just yet.

The second way is to grant sudo access to the entire plugin, rather than directly to /sbin/service. The nice part about that is greater flexibility (no need to change all three if/else segments), with the obvious major caveat that you better not allow write privileges to that file to anyone other than root. If you wanted to go that route, you'd add this to your sudoers file: and change the command definition to have sudo at the beginning. For the XI server itself, that'd be in the Core Config Manager under Commands, changing '$USER1$/check_init_service $ARG1$' to ' sudo $USER1$/check_init_service $ARG1$', and for remote systems in the nrpe config file. Again, there's some security risk to this route, so you'll want to make sure you've changed permissions on check_init_service to address that if necessary.