Description of problem: If an alert triggers in RHQ and SNMP alert senders are enabled, SNMP packets will not be sent to the configured SNMP MIB (the host that receives the SNMP packets). Version-Release number of selected component (if applicable): RHQ, master branch, 12/15/09 git pull How reproducible: Always Steps to Reproduce: 1. Create an alert and enable the SNMP alert sender 2. On the MIB, make sure your SNMP ports are open, and run a tcpdump -i eth0 udp | grep <ip of RHQ server> Actual results: No SNMP packets sent when alerts trigger Expected results: SNMP packets sent when alerts trigger Additional info:
Steve, I think this is/was caused by the usage of desination port 161, where 162 is the right one. With the correct destination port, an snmptrapd instance shows the following in syslog Jan 13 12:20:36 snert snmptrapd[8929]: 0.0.0.0: Cold Start Trap (0) Uptime: 0:00:00.00, iso.2.3.4.5.6.7.1 = STRING: "test2", iso.2.3.4.5.6.7.2 = STRING: "snert-e", iso.2.3.4.5.6.7.3 = STRING: "snert-e", iso.2.3.4.5.6.7.4 = STRING: "\n- Bedingung 1: Free Memory < 2,0GB\n- Datum/Uhrzeit: 2010/01/13 12:20:28 MEZ\n - Details: 41,0MB\n", iso.2.3.4.5.6.7.5 = STRING: "!! - medium", iso.2.3.4.5.6.7.6 = STRING: "http://localhost:7080/alerts/Alerts.do?mode=viewAlert&id=10001&a=10001" I am not sure if tcpdump can see the snmp packet sent when you are sending to localhost and tcpdump is listening on eth0 instead of lo0 Default port has been changed in 67943fe
Second change (if port is not set in configuration) is in f00ad9a
Alas, my SNMP trap OID was set to a string and not an integer, and, as such, the SNMP Alert Sender was failing to send an SNMP trap. Changing this maligned option caused traps to flow appropriately; thus, this bug is verified.
mass move to rhq_chainsaw tracker bug
This bug has now been triaged by Chainsaw on 2/18. The expectation is the bug to be addressed by the end of sprint06 roughly 3/10/10.
moving verified bugs to rhq_sprint06, and removing from rhq_chainsaw
Mass-closure of verified bugs against JON.