Solved snmpd spams log with "error on subcontainer 'swrun container' insert (-1)"

Hi,

this is a freshly set-up machine, FreeBSD 10.1-RELEASE-p10 with net-snmp-5.7.3_7.
snmpd.conf looks like this

Code:
rocommunity  public
dontLogTCPWrappersConnects 1
I see a lot of
Code:
error on subcontainer 'swrun container' insert (-1)
log entries, approx. 1 for every connect.

There is an old PR with the same problem, which got fixed upstream (Version 5.7.2):
PR 164898.

The server has one network card (em0) and the lo0 interface.

Anyone experiencing the same error?
 
Update:
only one OID triggers the log entries:
snmpget -c public -v 2c 127.0.0.1 1.3.6.1.2.1.25.1.6.0
Code:
1.3.6.1.2.1.25.1.6.0
is
Code:
number of running processes
Other OIDs work fine. A different server (same OS and net-mgmt/net-snmp versions) does not have that issue.
tcpdump did not look different from working server.
 
Fixed it somehow.
Added snmpd_flags="-Lf /var/log/snmpd.log -LE 6" to /etc/rc.conf and the log messages go away.
Seems that this box has a log level of LOG_DEBUG, don't really know why, can not see any related changes to the port in the last weeks (other box with same snmpd.conf, package and FreeBSD version does not have that issue).
Resting my case now, maybe this helps someone else.
 
Fixed it somehow.
Added snmpd_flags="-Lf /var/log/snmpd.log -LE 6" to /etc/rc.conf and the log messages go away.
Seems that this box has a log level of LOG_DEBUG, don't really know why, can not see any related changes to the port in the last weeks (other box with same snmpd.conf, package and FreeBSD version does not have that issue).
Resting my case now, maybe this helps someone else.
Hello, this is not a fix, the real solution is to create a new snmpd.conf by snmpconf -g basic_setup that said SirDice https://forums.freebsd.org/threads/29240/#post-279297
 
My system still runs OK since Mar-22-2017
Code:
root@server:~ # ls -la /var/log/snmpd.log
-rw-r--r--  1 root  wheel  127 Apr 27 10:09 /var/log/snmpd.log
root@server:~ # cat /var/log/snmpd.log
mibII/mta_sendmail.c:open_sendmailst: could not guess version of statistics file "/var/log/sendmail.st"
NET-SNMP version 5.7.3
root@server:~ # uname -a
FreeBSD mydomain 11.0-RELEASE-p8 FreeBSD 11.0-RELEASE-p8 #1: Mon Mar  6 17:39:37 COT 2017     root@mydomain:/usr/obj/usr/src/sys/TCPOPEN  amd64
root@server:~ # pkg info | grep net-sn
net-snmp-5.7.3_16              Extendable SNMP implementation
root@server:~ #
I will try to test with new kernel then I recompile to my TCPOPEN, this is the unique difference that I see. Note that my net-snmp-5.7.3_16 is update
 
Do you fetch the OID above? 1.3.6.1.2.1.25.1.6.0. Otherwise I do not see the log entry.
 
I was Updating, Building and Installing my Custom Kernel TCPOPEN
root@server:~ # uname -a
FreeBSD mydomain 11.0-RELEASE-p10 FreeBSD 11.0-RELEASE-p10 #2: Mon May 1 16:45:25 COT 2017 root@mydomain:/usr/obj/usr/src/sys/TCPOPEN amd64

I use to snmpget -i in order to customize
Code:
snmp
 
Do you fetch the OID above? 1.3.6.1.2.1.25.1.6.0. Otherwise I do not see the log entry.

root@server:~ # snmpget -c public -v 2c 127.0.0.1 1.3.6.1.2.1.25.1.6.0
HOST-RESOURCES-MIB::hrSystemProcesses.0 = Gauge32: 2
root@server:~ # cat /var/log/snmpd.log
mibII/mta_sendmail.c:open_sendmailst: could not guess version of statistics file "/var/log/sendmail.st"
Turning on AgentX master support.
Turning on AgentX master support.
Turning on AgentX master support.
NET-SNMP version 5.7.3
Connection from UDP: [127.0.0.1]:62316->[127.0.0.1]:161
Received SNMP packet(s) from UDP: [127.0.0.1]:62316->[127.0.0.1]:161
root@server:~ #
 

root@server:~ # snmpget -c public -v 2c 127.0.0.1 1.3.6.1.2.1.25.1.6.0
HOST-RESOURCES-MIB::hrSystemProcesses.0 = Gauge32: 2
root@server:~ # cat /var/log/snmpd.log
mibII/mta_sendmail.c:open_sendmailst: could not guess version of statistics file "/var/log/sendmail.st"
Turning on AgentX master support.
Turning on AgentX master support.
Turning on AgentX master support.
NET-SNMP version 5.7.3
Connection from UDP: [127.0.0.1]:62316->[127.0.0.1]:161
Received SNMP packet(s) from UDP: [127.0.0.1]:62316->[127.0.0.1]:161
root@server:~ #
Thanks wmoreno3 for trying to reproduce, seems to be a problem on my end and it will very likely not get resolved anymore as I'm moving on.
 
Back
Top