Nagios Support Forum

Linux Distro & Version: CentOS Stream 8
XI Version: 5.11.2

We upgraded from CentOS Stream 7 to 8 following this procedure https://assets.nagios.com/downloads/nag ... ios-XI.pdf and noticed that the SNMP Traps service for each host does not update when a trap is received. This was working before upgrading.

The SNMP Trap Interface correctly shows our defined traps, as well as showing the received traps both in the web interface and the snmptt.log file. However, the SNMP Traps service for the corresponding hosts, generated by the SNMP Trap Configuration Wizard, remain "OK" and don't update when a trap is received.

Any ideas on how I should proceed?

Thanks.

Hi @RDom,

Can you post a screenshot of the Trap Definition for these traps? I was able to get sample traps to be reflected under the SNMP Traps service for a new host I made by adding the host name to the "Host Name" field and making sure "Enable Passive Service Setup" was toggled on.

Hi,

Here are some screenshots for the specific trap I was using to test. It's worth to mention that this isn't an isolated issue, all traps are also having the same issue.

The received tab cuts off part of the host name but I assume that's just a CSS thing since the log files show the full (correct) name.

Sorry, I should have been more specific about the config settings I was looking to confirm:

You'll need to hit the "edit" icon on the Trap definition: And then scroll to the Passive Service Setup segment We'll need to make sure the host settings point to the correct host.

Apologies for the misunderstanding. I attached what it currently looks like.

I would also like to note that I did try and change the host to the one I was testing and that didn't work either.

I don't believe this is the root cause of your problem, however it looks like you are defining traps with exec lines that include "--trap_hostname='$R' --trap_ip='$r'". Per the Exec Macro reference, both $r and $R are aliases for the hostname, so most likely the value being logged for trap_ip is not correct. If you have the same IP as hostname here this may not matter but I figured I'd point it out as it jumped out at me while going over your screenshots.

Since you're using the hostname macro to determine what host the trap is associated with, you'll need to make sure the hostname value being sent in the trap exactly matches the hostname you ran the wizard against. If this isn't the case, hopefully correcting that issue will resolve this problem. If not, the next best step to diagnose this will most likely be to open a case with our support department.

I've included a link here in case that ends up being the best solution.

No luck unfortunately, that doesn't seem to be the issue.

I've opened a ticket, thanks for the help.