Description of problem:
A connected agentx subagent will crash on an snmpd stop or restart. The backtrace shows the crash originates in libnetsnmp snmp_sess_close.
Debugging shows the crash is within netsnmp_transport_free [SNMP_FREE(t)]. The transport pointer (t) is null and the final backtrace call is in glibc.
Prior to the crash any queries to snmpd for OID's the subagent is registered for gets a `Timeout: no response from localhost`.
Both the agent and the snmpd foreground process show the agent connects successfully.
Version-Release number of selected component (if applicable):
Every time snmpd is stopped or restarted with a connected net-snmp AgentX subagent written against the 5.7.2-24 library.
Steps to Reproduce:
1. Connect AgentX sub-agent to snmpd running foreground or background
2. Restart or Stop snmpd
3. AgentX sub-agent will crash with mention of a double free in glibc. Backtrace and debugging shows this call is made from within netsnmp_transport_free.
The subagent thread will crash bringing down any application process it is running within.
No crash on snmp stop/restart. snmpget to registered OID's of the subagent should return data, not timeouts.
This subagent was developed on Fedora 25 with net-snmp-5.7.3-13 where the crash does not exist. A stop restart of snmpd either in the foreground or background simply results in the subagent attempting a reconnect every 15 seconds.
The same correct behavior can be seen with the same code compiled on Ubuntu 16.04 with the libsnmp 5.7.3.
Additionally, the OID's mentioned previously are found and reported properly - with no change in the associated MIB's.
The issue only exists when the subagent is compiled against net-snmp-5.7.2-24.
Thank you for taking the time to report this issue to us. We appreciate the feedback and use reports such as this one to guide our efforts at improving our products. That being said, this bug tracking system is not a mechanism for requesting support, and we are not able to guarantee the timeliness or suitability of a resolution.
If this issue is critical or in any way time sensitive, please raise a ticket through the regular Red Hat support channels to ensure it receives the proper attention and prioritization to assure a timely resolution.
For information on how to contact the Red Hat production support team, please visit:
Red Hat Enterprise Linux version 7 is entering the Maintaining phase 1 of its lifetime and this bug doesn't meet the criteria for it, i.e. only high severity issues will be fixed. Please see https://access.redhat.com/support/policy/updates/errata/ for further information.
This issue should be fixed in Red Hat Enterprise Linux 8.
Closing as WONTFIX.