Nagios Support Forum

It is part of the snmptrapd script, so perhaps that is just part of the SNMPTT install package? Anyways, as long as we can figure out why that option is there and whether or not it's required.

Thanks!

Is this something that is part of your scripted SNMP install, or should someone else be notified?

Ooookay, progress! I figured that since all other services could restart/stop/reload with no issues, it was not the 'functions' file, but most likely a problem with '/etc/init.d/snmptrapd'. I compared the stop function in there to our old Nagios server: Old: killproc /usr/sbin/snmptrapd New: killpro...

Okay, I ran the new SNMP script on our test VM, and now snmptrapd is exhibiting the same behaviour - pidof: invalid options on command line! Could it be that there's a typo or something in that script? Or perhaps it updates something twice that then breaks snmptrapd? Also...should I re-post this in ...

I'll probably re-build another VM and see if I can reproduce the error at some point, but it's working now, so good enough to continue the deployment.

Yes, I still need to configure for the traps from this particular host, just have not done that yet. Thanks for all your help!

Yes, I had set that to '1' before. Ran the script, it also had issues when it came to restarting snmptrapd, same errors. I killed the PID and started the service again. The unknown traps are coming through to the unknown log, nice. Is it safe to say at this point that the SNMP portion of the server ...

Nothing showing up in the unknown log (hasn't been created yet, even). System log shows: Fri Oct 21 11:27:25 2011 SNMPTT v1.3 started Fri Oct 21 11:27:25 2011 Loading /etc/snmp/snmptt.conf.snip Fri Oct 21 11:27:25 2011 Finished loading 89 lines from /etc/snmp/snmptt.conf.snip Fri Oct 21 11:27:25 201...

Update on this: Starting to look like while we have issues, the real reason why traps are not coming in is that the sending server was misconfigured/buggy.

Still trying to sort out why that service is failing to stop/restart however, along with the other issues present.

Hm, progress....I think. I am manually sending traps (as per: http://technotes.twosmallcoins.com/?p=369 ) and I'm seeing them in the logs! This is from /var/log/snmptrapd.log : couldn't open udp:1622011-10-20 13:34:32 localhost [127.0.0.1] (via UDP: [senderIPredact]:60640->[nagiosIPredact]) TRAP, SN...

I took that snmptrapd text and created a new snmptrapd file in /etc/init.d/, used that to get status, works. Used it to restart, fails with the same error.

The files are not identical, but either way, it fails, so that's not it.