Nagios Support Forum

Sorry for the late reply, I was out last week...

hostname.ilo is the ilo and just the hostname is the server. The ilos are set to send traps as the server names, but the traps have the ilo addresses in syslog and snmptt.log. Traps in Nagios are on the ilos. The servers are not set up to send traps, nor do they have the trap monitor configured to listen for traps.

# nslookup txslm2mvesx001.ilo | grep -e ^Name -e ^Address
Address: 10.133.134.10#53
Name: txslm2mvesx001.ilo.m2m.local
Address: 10.133.133.60

]# nslookup txslm2mvesx001 | grep -e ^Name -e ^Address
Address: 10.133.134.10#53
Name: txslm2mvesx001.m2m.local
Address: 10.133.134.70

Is the DNS port #53 on the end of the host address generating any errors? Just an idea.

I'm surprised that there aren't any errors being logged at all. Can you confirm that snmptt is logging anything- maybe generate an alert. Then try running the snmptrap command manually from the command line using the hosts in question and post both the command being run (redacted for privacy) and the log itself. Also you have to make sure snmptt is in debug mode like we mention on page 2.

The #53 is just part of the output of nslookup that I didn't filter out. Nslookup outputs the nameserver address along with the host you're looking for. That isn't a problem at all.

I've posted the results of debugging before.

Let's do this:
Now generate an ILO trap and you should see the trap show up in a file here:
Please post the full output of that trap file.

When you are done you can start the snmptt service:

I'm not sure what problem you're trying to solve.
My issues were fixed by changing the description back to SNMP Traps, and restarting the stalled snmptt service (running but not working).

Oh.. sorry about that. I'm glad it's working for you, can we mark this as resolved and lock the topic?

One last question...
snmptt locked up again Friday and stopped processing traps. Looks like it does this about every other week. Its still running and the snmptt service monitor doesn't alert. When its restarted, it says it failed to stop, and there's a flood of alerts.
Modifying values in trap translation, adding MIBs shouldn't lock up snmptt, should it? I'd think the change wouldn't take effect.

Adding MIBs and changing values shouldn't cause the snmptt daemon to hang as far as we know.
Are there any errors in the logs?

It was locked up again today when I checked...
I guess I'll need to restart it hourly, or find a way to tell it isn't working and create an event handler, or something.
All the logs show is the restart about 2 hours ago (UTC).

# grep -i snmptt /var/log/messages | grep -v authenticationFailure | grep -v NORMAL | grep -v INFORM | grep -v CRITICAL | grep -v "Status Events"
Oct 5 17:36:59 txslm2mlnag001 snmptt-sys[0]: SNMPTT v1.3 started
Oct 5 17:36:59 txslm2mlnag001 snmptt-sys[0]: Loading /etc/snmp/snmptt.conf
Oct 5 17:36:59 txslm2mlnag001 snmptt-sys[0]: Finished loading 5805 lines from /etc/snmp/snmptt.conf
Oct 5 17:36:59 txslm2mlnag001 snmptt-sys[0]: Changing to UID: snmptt (502)
[root@txslm2mlnag001 services]#

# grep -i snmp /var/log/snmptt/snmptt.log* | grep -v authenticationFailure | grep -v "Status Events"

Could you post more of the log files here, starting a few minutes before the restart and after?
That would help out in debugging this.