bin/160494: bsnmpd returns inaccurate data for hrSystemProcesses OID

Jeremy Chadwick freebsd at jdc.parodius.com
Mon Sep 5 22:50:04 UTC 2011


>Number:         160494
>Category:       bin
>Synopsis:       bsnmpd returns inaccurate data for hrSystemProcesses OID
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    freebsd-bugs
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:
>Class:          change-request
>Submitter-Id:   current-users
>Arrival-Date:   Mon Sep 05 22:50:03 UTC 2011
>Closed-Date:
>Last-Modified:
>Originator:     Jeremy Chadwick
>Release:        FreeBSD 8.2-STABLE amd64
>Organization:
>Environment:
System: FreeBSD icarus.home.lan 8.2-STABLE FreeBSD 8.2-STABLE #0: Tue Aug 23 18:20:42 PDT 2011 root at icarus.home.lan:/usr/obj/usr/src/sys/X7SBA_RELENG_8_amd64 amd64
>Description:
	(CC'ing maintainer of ports/net-mgmt/net-snmp, since said port has
	the exact same problem described below.  Maintainer may want to report
	this upstream to the net-snmp folks, since based on my review of the
	net-snmp code this looks like it affects multiple BSDs (any BSD that
	implements kvm_getprocs(3), sans Darwin which has its own code))

	bsnmpd(8)'s support for HOST-MIB has a "bug" where the hrSystemProcesses
	OID returns an inaccurate number of system processes.  On a machine with
	~50 actual processes, hrSystemProcesses.0 reports 240 or so (this will
	vary per machine configuration/driver/etc. given the nature of the issue).

	The root cause is use of KERN_PROC_ALL when calling kvm_getprocs(3) in
	src/usr.sbin/bsnmpd/modules/snmp_hostres/hostres_scalars.c, function
	OS_getSystemProcesses.  KERN_PROC_ALL, per the kvm_getprocs(3) man page,
	includes system processes *as well* as visible kernel threads.

	According to the official HOST-MIB, hrSystemProcesses should be the
	"number of process contexts currently loaded or running"; the "industry
	norm" is to return system process counts only:

	http://www.net-snmp.org/docs/mibs/host.html

	Comparatively, for hrSystemProcesses, both Linux and Solaris 10 return the
	actual number of processes running on the box and DO NOT include kernel
	threads.

	Use of KERN_PROC_ALL is also in function swrun_OS_get_procs in
	src/usr.sbin/bsnmpd/modules/snmp_hostres/hostres_swrun_tbl.c, however
	the comment at the top of the code indicates this is intentional ("Get all
	visible proceses including the kernel visible threads").  This code is
	used for the hrSWRun and hrSWRunPert OIDs.  I'm of the opinion that code
	SHOULD NOT be changed; hrSWRun can include things like kernel modules,
	so kernel thread count seems relevant there.

	However, the spelling mistake ("proceses") should be corrected.  :-)

	hrSystemProcesses behaviour varies per FreeBSD version.  Old RELENG_6
	(specifically 6.4-STABLE) returns just the process count; RELENG_7 and
	newer return the number of system processes in addition to kernel threads.
	I imagine the explanation is that some kernel innards changed between
	FreeBSD releases, but there is no mention of that change here:

	http://www.freebsd.org/doc/en/books/porters-handbook/freebsd-versions.html

	I would need to dig through kernel code to find the actual change that
	induced this.

	Finally, I want to point out that existing FreeBSD utilities like pkill
	have noted this change in the past.  See lines 318-319:

	http://www.freebsd.org/cgi/cvsweb.cgi/src/bin/pkill/pkill.c?annotate=1.4.2.5
>How-To-Repeat:
	Compare "snmpwalk -v2c -c community some.system.name hrSystemProcesses"
	count to that of ps -auxwww.
>Fix:
	In usr.sbin/bsnmpd/modules/snmp_hostres/hostres_scalars.c, function
	OS_getSystemProcesses, change KERN_PROC_ALL to KERN_PROC_PROC.

>Release-Note:
>Audit-Trail:
>Unformatted:


More information about the freebsd-bugs mailing list