David Miller wrote: > Hari Sekhon wrote: >> David Miller wrote: >>> I found one problem on my system. I think it was due to having >>> grsec compiled into the kernel, though there may have been a "secure >>> ps" package installed somewhere. >>> >>> The difference between "identical" systems where one worked and one >>> didn't is that running "ps" on the one that didn't work would only >>> show processes for that user, and it would take the real uid, not >>> the euid. So a "ps" never showed a nagios process. >> >> I've noticed this myself when installing hardened servers with grsec >> but the ps output should limit you to seeing processes that your user >> owns, right? > > Ah, then you are running grsec too? > >> So in that case if the check is run by the nagios user then it should >> be able to it's own process of nagios, so I don't think this is the >> issue. Root can of course see all procs. > > I found this by changing the nagios_check_command to be > /tmp/some_shell_script > > the shell script looked like this: > > #!/bin/sh > /usr/bin/id >> /tmp/check > /usr/lib/nagios/plugins/check_nagios /var/log/nagios/status.log 5 > '/usr/sbin/nagios' >> /tmp/check > /usr/lib/nagios/plugins/check_nagios /var/log/nagios/status.log 5 > '/usr/sbin/nagios' > > > And it would work. check_nagios would run fine and put the right > output in /tmp/check, and echo it back to the calling CGI. It just > wouldn't work if the cgi called check_nagios directly. > > But the id showed that the script was running as ruid www-data and > euid nagios; it could then run check_nagios which is a little weird. > But check_nagios itself, I'm sure, was still running as www-data and > thus unable to see nagios in a ps command. > > I'm assuming that sh would fork itself and exec() check_nagios, but > that when it did the fork it used the euid, not the ruid. I don't > have any other explanation for how it would work after and not before. > > If you've got things setup differently as far as ID's goes then none > of this applies, of course. I used the default ID's for both apache > (www-data) and nagios (nagios). > > > --- David >
well in that case I may as well not bother with it at all since I've already written a shell script to test nagios and email me if it's not running and that works via cron which is a much better test since it doesn't need nagios to tell me that nagios isn't working! I'm happy enough that it isn't complaining. I may change my mind at some point since downtime scheduling still doesn't work even though everything else does. I found that when I disabled the nagios_check_command line I was suddenly able to do comments which previously never worked, so it's highly possible that the scheduling is in some way connected to the nagios self check before it'll let you do it. Of course the error is completely bogus, a perms thing when I know that to be correct, I made no change to perms at all, just this check command when the error for comments suddenly changed from perms error to working and I am 100% positive I made no changes to anything else at that time. anyway, glad you got yours working the way you want. -h -- Hari Sekhon ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Nagios-users mailing list Nagios-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nagios-users ::: Please include Nagios version, plugin version (-v) and OS when reporting any issue. ::: Messages without supporting info will risk being sent to /dev/null