What were you trying to do that didn't work?

During reload, snmpd leaks the number of file descriptors equal to the number of trap destinations configured. [root@localhost# lsof -p $(pidof snmpd) | wc -l 57 [root@localhost# lsof -p $(pidof snmpd)>snmp1.out [root@localhost# systemctl reload snmpd [root@localhost# lsof -p $(pidof snmpd) | wc -l 67 [root@localhost# lsof -p $(pidof snmpd)>snmp2.out [root@localhost# diff snmp1.out snmp2.out 37c37 < snmpd 185338 root 3w REG 253,4 319 426 /var/log/snmpd.log — > snmpd 185338 root 3w REG 253,4 503 426 /var/log/snmpd.log 67a68,77 > snmpd 185338 root 35u IPv4 7012248 0t0 UDP *:46271 > snmpd 185338 root 36u IPv4 7012249 0t0 UDP *:49144 > snmpd 185338 root 37u IPv4 7012253 0t0 UDP *:54760 > snmpd 185338 root 38u IPv4 7012254 0t0 UDP *:41654 > snmpd 185338 root 39u IPv4 7012255 0t0 UDP *:44622 > snmpd 185338 root 40u IPv4 7012256 0t0 UDP *:46904 > snmpd 185338 root 41u IPv4 7012257 0t0 UDP *:42636 > snmpd 185338 root 42u IPv4 7012258 0t0 UDP *:46861 > snmpd 185338 root 43u IPv4 7012259 0t0 UDP *:45202 > snmpd 185338 root 44u IPv4 7012260 0t0 UDP *:51814

What is the impact of this issue to you?

When the snmpd process reaches the max file descriptor limit, it stops working, but remains a running process.  No SNMP get for monitoring and no SNMP traps for alerting are working.

Please provide the package NVR for which the bug is seen:

[root@localhost# rpm -qa|grep net-snmp
net-snmp-libs-5.9.1-17.el9.x86_64
net-snmp-agent-libs-5.9.1-17.el9.x86_64
net-snmp-5.9.1-17.el9.x86_64
net-snmp-utils-5.9.1-17.el9.x86_64

How reproducible is this bug?:

Always on available RHEL7 and RHEL9.

I compiled 5.10 from source on RHEL7 and the leak did not occur with the same configuration/system.

With NET-SNMP version 5.10 the issue appears fixed. Since the issue of fd leak happened the same on both RedHat 7 and Rocky 9, I don’t plan to setup and build a binary to test Rocky9, but I expect the same result. I just would like to know if this is acknowledged and when there will be a fix. The leak results in inoperable monitoring once the fd limit is reached, at least every 3 months.

[root@localhost# ps -ef|grep snmpd
root 8207 1 0 16:11 ? 00:00:00 net-snmp/snmpd -Lo /var/log/snmpd.log -f
[root@localhost# lsof -p 8207 |wc -l
22
[root@localhost# kill -HUP 8207
[root@localhost# lsof -p 8207 |wc -l
22
[root@localhost# kill -HUP 8207
[root@localhost# lsof -p 8207 |wc -l
22
[root@localhost#

Steps to reproduce

1. Edit snmpd.conf as below:
   #Config
   agentaddress udp:161
   syslocation Unknown
   syscontact root <root@localhost>
   trapcommunity public
   com2sec notConfigUser default public
   trap2sink 127.0.0.1:162 public
   trap2sink 10.0.0.1 public
   view limitedview included .1.3.6.1.4.1.674.10892
   view limitedview included .1.3.6.1.4.1.674.10893
   smuxpeer .1.3.6.1.4.1.674.10892.1
   smuxpeer .1.3.6.1.4.1.674.10892.5 iSMHostSNMPTrapForwarderFPI
2. Restricted to edit
   view limitedview included mib-2.system
   view limitedview included mib-2.snmp
   view limitedview included mib-2.interfaces
   view limitedview included mib-2.icmp
   view limitedview included mib-2.host
   view limitedview excluded mib-2.host.hrSWRun.hrSWRunTable.hrSWRunEntry.hrSWRunPath
   view limitedview excluded mib-2.host.hrSWRun.hrSWRunTable.hrSWRunEntry.hrSWRunParameters
   view limitedview excluded mib-2.host.hrSWInstalled
   view limitedview included private.enterprises.ucdavis.memory
   view limitedview included private.enterprises.ucdavis.systemStats
   view limitedview included private.enterprises.ucdavis.laTable
   view limitedview included private.enterprises.netSnmp.netSnmpObjects
   view limitedview included private.enterprises.1751
   view limitedview included 1.3.6.1.6.3.10
   group notConfigGroup v1 notConfigUser
   group notConfigGroup v2c notConfigUser
   access notConfigGroup "" any noauth exact limitedview none none
   access notConfigGroup "" any noauth exact limitedview none none
   agentgroup nobody
   master agentx
   agentXPerms 755 755 snmp snmp
   rouser user1
3. Restart snmpd
4. check fd count
5. reload snmpd
6. check fd count
7. compare both fdcdount outputs (increases by the number of trap destibations)
8. repeat if desired, same results

Expected results

No change in fd use

Actual results

increase in the number of file descriptors used, equal to the number of trap destinations configured.