"No output on stdout" error with check_snmp --rate

[apredeek]

Here are the /var/ permissions:

Code: Select all

ls -al /usr/local/nagios/var/
total 22524
drwxrwxr-x. 7 nagios nagios    4096 Jul  6 17:09 .
drwxr-xr-x. 9 root   root      4096 Apr 23  2015 ..
drwxrwxr-x. 2 nagios nagios   24576 Jul  5 23:59 archives
drws------  2 nagios nagios    4096 Jul  6 16:29 check_snmp
-rw-r--r--  1 nagios nagios    4463 Jul  6 17:09 host-perfdata
-rw-r--r--. 1 nagios nagios     334 Jul  6 12:18 nagios.configtest
-rw-r--r--  1 nagios nagios       6 Jul  6 12:18 nagios.lock
-rw-r--r--  1 nagios nagios  329613 Jul  6 17:06 nagios.log
-rw-rw-r--  1 nagios nagios 2020534 Jun  7 01:10 nagios.tmp0wn9h9
-rw-rw-r--. 1 nagios nagios 1493429 Nov 30  2015 nagios.tmpLRUcvC
-rw-rw-r--  1 nagios nagios 1458405 Feb  1 01:22 nagios.tmpn3Rpv7
-rw-rw-r--. 1 nagios nagios  851554 Jun 27  2015 nagios.tmppLlwXn
-rw-r--r--  1 nagios nagios       5 Jul  5 11:44 ndo2db.lock
-rw-r--r--  1 nagios nagios       0 Jul  6 12:18 ndomod.tmp
srwxr-xr-x  1 nagios nagios       0 Jul  5 11:44 ndo.sock
-rw-r--r--. 1 nagios nagios 3388807 Jul  6 12:56 npcd.log
-rw-r--r--. 1 nagios nagios 1388234 Jul  6 12:18 objects.cache
-rw-r--r--. 1 nagios nagios 1388234 Jul  6 12:18 objects.precache
-rw-rw-r--. 1 nagios nagios 6494563 Jul  6 12:56 perfdata.log
-rw-------  1 nagios nagios 2070658 Jul  6 16:18 retention.dat
drwxrwsr-x. 2 nagios nagcmd    4096 Jul  6 12:18 rw
-rw-r--r--  1 nagios nagios   16925 Jul  6 17:09 service-perfdata
drwxr-xr-x. 5 nagios nagios    4096 Apr 23  2015 spool
drwxr-xr-x. 2 nagios nagios    4096 Jul  6 17:09 stats
-rw-rw-r--  1 nagios nagios 2060756 Jul  6 17:09 status.dat

I removed the check_snmp folder and ran the command again, but it did not recreate the folder and returned the segmentation fault again. I ran the 'test check command' again and it completed successfully, creating the folder and a file. (I think the earlier file had been deleted as part of troubleshooting several days ago, hence the previously empty directory. Sorry for the confusion.)

Here are the folder permissions after it was created by the 'test check command':

Code: Select all

ls -al /usr/local/nagios/var/
total 22520
drwxrwxr-x. 7 nagios nagios    4096 Jul  6 17:19 .
drwxr-xr-x. 9 root   root      4096 Apr 23  2015 ..
drwx------  2 apache apache    4096 Jul  6 17:13 check_snmp

And here are the permission on the check_snmp plugin:

Code: Select all

ls -al /usr/local/nagios/libexec/check_snmp
-rwsrwxr-x. 1 apache nagios 251289 Apr 23  2015 /usr/local/nagios/libexec/check_snmp

[rkennedy]

This is really strange, as when you run as the root / nagios user it should have sufficient permissions to create the folder. I'm baffled why apache is able to without any problems.

What version of the plugin are you running? ./check_snmp -V?

[apredeek]

check_snmp v2.0.3 (nagios-plugins 2.0.3)

[rkennedy]

A coworker noticed this, your x bit is actually set to 's'. This will affect how check_snmp functions. You'll want to fix the permissions accordingly. Here's the permissions on my check_snmp file -

Code: Select all

-rwxrwxr-x. 1 apache nagios 255972 Mar 29 09:59 check_snmp

Additionally, do you have SELinux running on the machine currently? getenforce

[apredeek]

I had to also delete the var/check_snmp/ directory again to force recreation with correct permissions, but it appears to be working now.

Here are the current, working permissions:

Plugin:
ls -l | grep check_snmp$
-rwxrwxr-x. 1 apache nagios 251289 Apr 23 2015 check_snmp

Directory:
ls -l /usr/local/nagios/var
drwx------ 2 nagios users 4096 Jul 7 13:24 check_snmp

Thanks a lot for the assistance!

[rkennedy]

I had to also delete the var/check_snmp/ directory again to force recreation with correct permissions, but it appears to be working now.

Here are the current, working permissions:

Plugin:
ls -l | grep check_snmp$
-rwxrwxr-x. 1 apache nagios 251289 Apr 23 2015 check_snmp

Directory:
ls -l /usr/local/nagios/var
drwx------ 2 nagios users 4096 Jul 7 13:24 check_snmp

Thanks a lot for the assistance!

Awesome, I forgot about re-creating the directory (since that would have been issues down the road), so nice catch!

Are we good to mark this one as resolved?

[apredeek]

Yep, we're good to call it resolved.

Thanks again!

[mcapra]

Closing this per your request