Bug 1252048 - net-snmp snmpd fork() overhead [fix available]
net-snmp snmpd fork() overhead [fix available]
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: net-snmp (Show other bugs)
All Linux
unspecified Severity medium
: rc
: ---
Assigned To: Jan Safranek
Dalibor Pospíšil
Depends On:
  Show dependency treegraph
Reported: 2015-08-10 10:36 EDT by Dalibor Pospíšil
Modified: 2015-11-19 06:46 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Cause: To improve security and to prevent file descriptor leaks, snmpd always closes all its filedescriptors when processing 'extend' or 'pass' configuration options. Doing so, it blindly closes all filedescriptors lower than current resource limit of opened files (ulimit -n, /proc/sys/fs/file-max). Consequence: When these limits are high, it may take some time to close these filedescriptors and snmpd thus slowly reacts to GET request in NET-SNMP-EXTEND-MIB::nsExtendOutput1Table. Fix: snmpd does not read resource limits from operating system, instead it finds out on its own which file descriptors it uses. Result: Requests in NET-SNMP-EXTEND-MIB::nsExtendOutput1Table are much faster.
Story Points: ---
Clone Of: 1188295
Last Closed: 2015-11-19 06:46:12 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Dalibor Pospíšil 2015-08-10 10:36:47 EDT
+++ This bug was initially created as a clone of Bug #1188295 +++

Description of problem:

NB. This is not limited to RHEL6 (also affects RHEL5/7).

Due to the way snmpd handles file descriptors when forking scripts for 'pass' or 'extend', on systems with very large numbers of FD, this will consume CPU and take several seconds for each OID.

Please consider back porting the following fix:

Version-Release number of selected component (if applicable):
Observed on all releases, including 5.7

How reproducible:
Every time

Steps to Reproduce:
1. increase fs-max/nofile to large value (32626630 in test case)
2. configure snmp pass or extend in snmpd.conf
3. get/walk the OID

Actual results:
Several seconds of 100% CPU utilisation, SNMP response takes several seconds.
snmpwalk (for 'pass' that support this) time out.

Expected results:
Immediate response, minimal CPU utilisation

Additional info:
Please consider back porting the following fix:
Comment 4 errata-xmlrpc 2015-11-19 06:46:12 EST
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.


Note You need to log in before you can comment on or make changes to this bug.