Nagios Support Forum

Hey Crew,

Months ago I found a bug in the Nagiosxi-SNMPTrap.sh script but completely forgot to report it... I accidently just reminded myself when copying over an old config file.

The install script will configure SNMPTT in standalone mode rather than in daemon mode... it goes through and configures most of the options for daemon mode but misses two crucial steps:
1. It never copies the snmptthandler executable to /usr/sbin/ or /usr/local/sbin, which is required for submitting to an SNMPTT daemon.
2. It configures /etc/snmp/snmptrapd.conf to use /usr/local/sbin/snmptt (instead of /usr/sbin/snmptthandler) as the traphandle which causes SNMPTT to run in standalone mode.

This has a profound impact on performance for SNMP trap heavy environments... in my case it causes a 50% drop in CPU utilization when configured correctly.

Hey ...

Thanks for raising this ...I have a feeling some of my boxes are affected by this , I will look into them..

Cheers
Arnab

jsmurphy wrote:Hey Crew,

Months ago I found a bug in the Nagiosxi-SNMPTrap.sh script but completely forgot to report it... I accidently just reminded myself when copying over an old config file.

The install script will configure SNMPTT in standalone mode rather than in daemon mode... it goes through and configures most of the options for daemon mode but misses two crucial steps:
1. It never copies the snmptthandler executable to /usr/sbin/ or /usr/local/sbin, which is required for submitting to an SNMPTT daemon.

...

I am a bit lost here...cant find anything like that on my system ...can you help me...please...

2. It configures /etc/snmp/snmptrapd.conf to use /usr/local/sbin/snmptt (instead of /usr/sbin/snmptthandler) as the traphandle which causes SNMPTT to run in standalone mode.

This has a profound impact on performance for SNMP trap heavy environments... in my case it causes a 50% drop in CPU utilization when configured correctly.

Hi All,

Can anybody help me with this after I changed the handler to snmptthandler the traps no longer translate the oids. I am now getting enterprises.6486.800.1.2.1.16.1.1.6.2 instead of healthMonDeviceTrap

Thanks
Arnab

Arnab, at this time this bug is neither confirmed nor denied, it could be a local environment bug or a wide spread one. I would suggest reverting any changes you made until we dig into this issue.

arnab.roy wrote:Hi All,

Can anybody help me with this after I changed the handler to snmptthandler the traps no longer translate the oids. I am now getting enterprises.6486.800.1.2.1.16.1.1.6.2 instead of healthMonDeviceTrap

Thanks
Arnab

Ah what slansing said... I probably wouldn't go changing anything just yet. I discovered this back in March, so there's a very real possibility that the install script has changed since then. I did cast my eyes quickly over the latest version of the script and the bug appeared as though it was still present, but I would wait until they confirm it and come up with a set of official steps to fix it.

Mostly because I can't remember exactly what I did back in March to make it go away other than what I mentioned

HI All,

I can cofirm that the bug does indeed exist...what is happening is that the script creates an init script for snmptt so it forks out and runs in the background as well as it keeps calling the snmptt binary via the snmptrapd.conf. Their is no need to for it to run in two different places. Their is something seriously wrong somewhere as I just found out of 3 remote xi servers 2 which are installed under heavy snmptrap usage had frozen snmptrapd's and it would even kill . Can this be investigated with some priority....

Many Thanks
Arnab

Interesting. This sounds very similar to the issue I just submitted in another post. We recently upped the amount of traps we are receiving significantly and within 12-14 hours of doing this, trap reception stopped working until snmptrapd was restarted. There are two snmptt pids running for me as well. However, since you mentioned that the snmptt binary is called via the snmptrapd.conf, I just stopped snmptt all together and confirmed that traps still come in ok, so not exactly sure what role snmptt as a service is playing?

Thanks!

Bryant

arnab.roy wrote:HI All,
Their is something seriously wrong somewhere as I just found out of 3 remote xi servers 2 which are installed under heavy snmptrap usage had frozen snmptrapd's and it would even kill...

From my testing way back, the snmptrapd service seems to stop processing if you receive a consistently large number of traps and the new SNMPTT instance(s) take too long to fire. This is merely my best guess, once I was able to reduce the trap load, the problem of the trap daemon stopping went away.

bvinisky wrote: I just stopped snmptt all together and confirmed that traps still come in ok, so not exactly sure what role snmptt as a service is playing?

SNMPTT translates the traps into human readable format, the reason the traps are still coming through is because what you have stopped is the SNMPTT daemon, but it is still firing off standalone instances of the application. The reason why this matters is because in standalone mode it will re-read all of your translation definitions for every trap received... in my case that's about 160,000 lines of flat file for every single trap. In daemon mode it only ever reads your translations once, much like Nagios only ever reads your configuration files once on start-up.

Hi js ,

yes exactly my point , i have the same problem, my trap def file is massive, i got it working in the daemon mode using the snmptthandler from the original package . But the only problem i am getting is when in daemon mode it ignores the snmptt.ini entry of translate_trapoids. So when the alert for the trap comes through it contains the numeric oid instead of the translated string...

Any pointers how i can fix this ? Almost all nms platforms use snmptrapd however they dont tank like this everytime there is a burst of snmp traps , we definitely need an official answer here guys ...


Much appreciate everyones input ..here..

Thanks