Bug 215471 - Using bsnmpd with the snmp_hostres module on a vmware ESXi guest with a disconnected CD drive uses 100% CPU
Summary: Using bsnmpd with the snmp_hostres module on a vmware ESXi guest with a disco...
Status: Closed DUPLICATE of bug 209368
Alias: None
Product: Base System
Classification: Unclassified
Component: misc (show other bugs)
Version: 11.0-RELEASE
Hardware: amd64 Any
: --- Affects Some People
Assignee: freebsd-stable mailing list
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-12-21 15:07 UTC by jimp
Modified: 2018-05-14 17:15 UTC (History)
10 users (show)

See Also:


Attachments
A configuration file for bsnmpd which can reproduce the high CPU usage problem on a vmware guest (293 bytes, text/plain)
2016-12-21 15:07 UTC, jimp
no flags Details
"top -aSH" output while bsnmpd is consuming all CPU (2.74 KB, text/plain)
2016-12-21 15:07 UTC, jimp
no flags Details
A portion of the output from "truss -f /usr/sbin/bsnmpd -p /var/run/snmpd.pid" while it is consuming all CPU (84.97 KB, text/plain)
2016-12-21 15:08 UTC, jimp
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description jimp 2016-12-21 15:07:04 UTC
Created attachment 178177 [details]
A configuration file for bsnmpd which can reproduce the high CPU usage problem on a vmware guest

When running FreeBSD 11.0-RELEASE (from release until at least -p5), there is a combination of factors that leads to bsnmpd using 100% CPU.

It seems to require all of the following:

* FreeBSD 11 running as a guest in VMWare ESXi
* The guest has a "CD/DVD Drive" listed in its hardware on ESX
* The CD/DVD Drive is in a disconnected state
* The snmp_hostres module is loaded in the bsnmpd configuration file
* bsnmpd enabled and running

Here is a very small snmpd.config that can replicate the problem in a similar environment:

==================
%snmpd
sysDescr			= "FreeBSD doctor.example.com FreeBSD 11.0-RELEASE-p5 amd64"
begemotSnmpdCommunityString.0.1 = "supersecret"
begemotSnmpdPortStatus.0.0.0.0.161 = 1
begemotSnmpdModulePath."mibII"  = "/usr/lib/snmp_mibII.so"
begemotSnmpdModulePath."hostres"     = "/usr/lib/snmp_hostres.so"
==================

If bsnmpd is run on this guest with that configuration, it consumes all available CPU. 

I'll attach the above snmpd.config, along with top output and a sample of the truss output taken while bsnmpd was running.

Currently the only workaround is to disable the hostres module, but that means losing access to any of the information it provides.
Comment 1 jimp 2016-12-21 15:07:51 UTC
Created attachment 178178 [details]
"top -aSH" output while bsnmpd is consuming all CPU
Comment 2 jimp 2016-12-21 15:08:43 UTC
Created attachment 178179 [details]
A portion of the output from "truss -f /usr/sbin/bsnmpd -p /var/run/snmpd.pid" while it is consuming all CPU
Comment 3 Scott Larson 2017-01-13 19:04:38 UTC
I've run into this myself. In the case of ESXi VMs my workaround has been to remove the cd device from the VM config. However I've noticed this is not limited to just that scope. This issue of relentlessly polling cd0 when the hostres module is enabled has also popped up on some purely physical installs as well.
Comment 4 emz 2017-08-11 09:34:13 UTC
Still there on r310734. With hostres module the bsnmpd stops handling SNMP get queries, and is useless. Workaround: disable the hostres module. Looks like he's stucking in disk discovering, at least this is the last that gets into the logs.
Comment 5 dustinwenz 2017-09-11 21:34:38 UTC
This is probably the same bug that has been in hostres for a while. Try applying the 1-line patch from this bug report and restart bsnmpd:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=209368
Comment 6 Eugene Grosbein freebsd_committer 2018-05-14 10:54:09 UTC
Should be fixed in all supported branches by https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=209368

Please check and respond.
Comment 7 Eugene Grosbein freebsd_committer 2018-05-14 10:56:08 UTC
*** Bug 217983 has been marked as a duplicate of this bug. ***
Comment 8 Conrad Meyer freebsd_committer 2018-05-14 17:15:40 UTC

*** This bug has been marked as a duplicate of bug 209368 ***