I discovered at the very least, a situation which causes the snmpd to run into a spin opening up /etc/mtab. I did a bit of discovery on the issue - I have tcpdump with full packet length + output from strace. I am not very familiar with gdb - if someone can give me the commands to use I would be happy to provide the results.
I have been able to track it down to the following OID get:
( the below is from a ticket I opened in my ticket system to work with this issue. The frame reference is the frame # in the pcap file - which I will provide if anyone wants to see it )
| fails at snmp get: 1.3.6.1.2.1.25.2.3.1.7
|
| see frame 229-230 for the last success->failure begin
|
| strace data from running snmpd:
|
| [EMAIL PROTECTED]:~# strace -fp 24179
|
| open("/etc/mtab", O_RDONLY|O_LARGEFILE) = 12
| close(12) = 0
| open("/etc/mtab", O_RDONLY|O_LARGEFILE) = 12
| close(12) = 0
| open("/etc/mtab", O_RDONLY|O_LARGEFILE) = 12
| close(12) = 0
| open("/etc/mtab", O_RDONLY|O_LARGEFILE) = 12
| close(12) = 0
| open("/etc/mtab", O_RDONLY|O_LARGEFILE) = 12
| ) = 0
|
| [EMAIL PROTECTED]:~# kill -9 24179
|
|
| packet capture attached.
|
| ----
|
| top lines from a previously run snmpd ( the one that started the debug
| process )
|
| USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
| root 1161 75.8 0.6 7216 3428 ? R 18:35 3:44
| /usr/sbin/snmpd -P /var/run/snmpd.pid
|
hrStorageAllocationFailures OBJECT-TYPE ~ SYNTAX Counter32 ~ MAX-ACCESS read-only ~ STATUS current ~ DESCRIPTION ~ "The number of requests for storage represented by ~ this entry that could not be honored due to not enough ~ storage. It should be noted that as this object has a ~ SYNTAX of Counter32, that it does not have a defined ~ initial value. However, it is recommended that this ~ object be initialized to zero, even though management ~ stations must not depend on such an initialization." ~ -- 1.3.6.1.2.1.25.2.3.1.7 -- ::= { hrStorageEntry 7 }
so it looks like this is dying at something in the storage entry section, per the doc, rfc2790.txt
time to look up this rfc, is this a bug in this peticular version of net-snmp or is this something the solarwinds get is causing to break
- ---- END of ticket comment -----
I initially discovered this issue working with net-snmp 5.1.1. When I
tested 5.1.2 on my system, the exact same behavior was observed. If I
run net-snmp 5.0.9 the system runs perfectly ( exact same snmpd.conf config ... )
What I find most interesting is this:
1) If I walk the system using the net-snmp snmpwalk, everything works just fine - nothing out of the ordinary.
2) If the system is walked by a product named Solarwinds, the system sends into the mtab bit
If there is any additional information I could provide, I can re-produce this issue at-will. Let me know if you want to see anything.
Thanks,
Bill Schwanitz
------------------------------------------------------- This SF.Net email is sponsored by OSTG. Have you noticed the changes on Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, one more big change to announce. We are now OSTG- Open Source Technology Group. Come see the changes on the new OSTG site. www.ostg.com _______________________________________________ Net-snmp-users mailing list [EMAIL PROTECTED] Please see the following page to unsubscribe or change other options: https://lists.sourceforge.net/lists/listinfo/net-snmp-users
