kern/126307: bsnmpd: UNIX socket leak on 6.3 when using Hostres-MIB

[Ulrich Spörlein]

>Number:         126307
>Category:       kern
>Synopsis:       bsnmpd: UNIX socket leak on 6.3 when using Hostres-MIB
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    freebsd-bugs
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Wed Aug 06 17:00:06 UTC 2008
>Closed-Date:
>Last-Modified:
>Originator:     Ulrich Spörlein
>Release:        FreeBSD 6.3-STABLE i386
>Organization:
>Environment:
	
>Description:
I think this is a kernel bug, as I have seen this happen with nss_ldap, too.
The process will grow wrt. to open files and eventually run out of file
descriptors or bring the system down.

Now I was running bsnmpd on my root-server for several months without problems,
and updated my system on July 22nd due to the bind issue, since then I have to
periodically restart bsnmpd to avoid resource starvation (last kernel was from
March 14).

Our production servers are still running on a kernel from early May, and they
too are not seeing the socket leak when running bsnmpd. I cannot reproduce the
problem on 7-STABLE either, so I'm sure it has been introduced to RELENG_6
during the last 3 months.

(The nss_ldap problem is happening on 6.1 and 6.2, too, so it is probably not
related).

>How-To-Repeat:
Use the sample snmpd.config and activate the mibII module and the hostres
module. Start bsnmpd.

Check open files:

# lsof -p `pgrep bsnmpd` | tail -5
bsnmpd  46945 root   10u  VCHR      0,101      0t0     101  () (like character special /dev/mdctl)
bsnmpd  46945 root   11r  VCHR        0,8      0t0       8  () (like character special /dev/null)
bsnmpd  46945 root   12r  VCHR        0,8      0t0       8  () (like character special /dev/null)
bsnmpd  46945 root   13u  IPv4 0xc364c168      0t0     UDP localhost:snmp
bsnmpd  46945 root   14u  unix 0xc4303b20      0t0         /var/run/snmpd.sock

run several snmpwalks:

# snmpwalk -v2c -c public localhost > /dev/null
# snmpwalk -v2c -c public localhost > /dev/null
# snmpwalk -v2c -c public localhost > /dev/null
# snmpwalk -v2c -c public localhost > /dev/null

and check open files again:
# lsof -p `pgrep bsnmpd` | tail -5
bsnmpd  46945 root   36u  unix 0xc38129bc      0t0         ->0xc3698de8
bsnmpd  46945 root   37u  unix 0xc3ad42c8      0t0         ->0xc3aeab20
bsnmpd  46945 root   38u  unix 0xc38122c8      0t0         ->0xc3c7cc84
bsnmpd  46945 root   39u  unix 0xc46e742c      0t0         ->0xc62366f4
bsnmpd  46945 root   40u  unix 0xc3bd6000      0t0         ->0xc3c6b6f4

continue till your system dies, as bsnmpd is running under root privileges :/
Another server of mine has bsnmpd running for 14 hours now, with SNMP polling
every five minutes. It is now at 184 open unix sockets.

>Fix:

	


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