From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040211 Firefox/0.8 Description of problem: It seems that passthrough scripts that execute other programs to get data to return have a higher chance of failing (much higher, in some cases) than scripts that don't. For example, the test passthrough script that comes with net-snmp 5.1.1 works most of the time (not always), but when I modify the script to execute a 'find' in the middle, it will sometimes (randomly) die there. If the script's first oid's output is the result of an external command, often snmpwalk will return "No Such Object available on this agent at this OID". This behavior is not experienced under a tarball install of net-snmp 5.0.9 on FC2, but is still observed with a tarball install of net-snmp 5.1.1 on FC2, thus I suspect the problem is within net-snmp itself. I've attached the output from snmpwalks against my modified passtest script, as well as the modified passtest script itself. Version-Release number of selected component (if applicable): net-snmp-5.1.1-2 How reproducible: Sometimes Steps to Reproduce: 1. write a pass-through script that executes other programs to gather the data it reports 2. snmpwalk or snmpget the oid that uses your pass-through script 3. watch it work some of the times, but not others. Additional info:
Created attachment 100430 [details] Log of executed snmpwalks
Created attachment 100431 [details] passtest script modified to execute an external command
Comment on attachment 100430 [details] Log of executed snmpwalks >[dwarner@webcode tmp]$ snmpwalk -v2c -c public server .1.3.6.1.4.1.2021.255 >UCD-SNMP-MIB::ucdavis.255.1 = STRING: "life the universe and everything" >UCD-SNMP-MIB::ucdavis.255.2.1 = INTEGER: 42 >UCD-SNMP-MIB::ucdavis.255.2.2 = OID: SNMPv2-SMI::private.42.42.42 >UCD-SNMP-MIB::ucdavis.255.2.3 = INTEGER: 19 >UCD-SNMP-MIB::ucdavis.255.3 = Timeticks: (363136200) 42 days, 0:42:42.00 >UCD-SNMP-MIB::ucdavis.255.4 = IpAddress: 127.0.0.1 >UCD-SNMP-MIB::ucdavis.255.5 = Counter32: 42 >UCD-SNMP-MIB::ucdavis.255.6 = Gauge32: 42 >[dwarner@webcode tmp]$ snmpwalk -v2c -c public server .1.3.6.1.4.1.2021.255 >UCD-SNMP-MIB::ucdavis.255.1 = STRING: "life the universe and everything" >UCD-SNMP-MIB::ucdavis.255.2.1 = INTEGER: 42 >UCD-SNMP-MIB::ucdavis.255.2.2 = OID: SNMPv2-SMI::private.42.42.42 >[dwarner@webcode tmp]$ snmpwalk -v2c -c public server .1.3.6.1.4.1.2021.255 >UCD-SNMP-MIB::ucdavis.255.1 = STRING: "life the universe and everything" >UCD-SNMP-MIB::ucdavis.255.2.1 = INTEGER: 42 >UCD-SNMP-MIB::ucdavis.255.2.2 = OID: SNMPv2-SMI::private.42.42.42 >UCD-SNMP-MIB::ucdavis.255.2.3 = INTEGER: 19 >UCD-SNMP-MIB::ucdavis.255.3 = Timeticks: (363136200) 42 days, 0:42:42.00 >UCD-SNMP-MIB::ucdavis.255.4 = IpAddress: 127.0.0.1 >UCD-SNMP-MIB::ucdavis.255.5 = Counter32: 42 >UCD-SNMP-MIB::ucdavis.255.6 = Gauge32: 42 >
Hm, i've been trying to reproduce the problem you reported, but couldn't reproduce it at all even after a couple of thousand runs of the snmpwalk request. Is your machine under load when you try this? How fast is the machine? Read ya, Phil
Machine is not under load at all; it's not the fastest box either; but the passthrough stuff all works under 5.0.9 compiled from source on FC2. Are there new resource or process time limits on passthrough scripts in Net-SNMP 5.1.1? The computers I've been testing on are new installs of FC2 using a kickstart file we built. CPU: P2 350MHZ Load Avg: 0.04, 0.01, 0.00 Just testing, I've been getting failures almost every time: [dwarner@webcode dwarner]$ snmpwalk -v2c -c public server .1.3.6.1.4.1.2021.255 UCD-SNMP-MIB::ucdavis.255.1 = STRING: "life the universe and everything" [dwarner@webcode dwarner]$ snmpwalk -v2c -c public server .1.3.6.1.4.1.2021.255 UCD-SNMP-MIB::ucdavis.255.1 = STRING: "life the universe and everything" UCD-SNMP-MIB::ucdavis.255.2.1 = INTEGER: 42 UCD-SNMP-MIB::ucdavis.255.2.2 = OID: SNMPv2-SMI::private.42.42.42 [dwarner@webcode dwarner]$ snmpwalk -v2c -c public server .1.3.6.1.4.1.2021.255 UCD-SNMP-MIB::ucdavis.255.1 = STRING: "life the universe and everything" UCD-SNMP-MIB::ucdavis.255.2.1 = INTEGER: 42 UCD-SNMP-MIB::ucdavis.255.2.2 = OID: SNMPv2-SMI::private.42.42.42 [dwarner@webcode dwarner]$ snmpwalk -v2c -c public server .1.3.6.1.4.1.2021.255 UCD-SNMP-MIB::ucdavis.255.1 = STRING: "life the universe and everything" UCD-SNMP-MIB::ucdavis.255.2.1 = INTEGER: 42 UCD-SNMP-MIB::ucdavis.255.2.2 = OID: SNMPv2-SMI::private.42.42.42 [dwarner@webcode dwarner]$ snmpwalk -v2c -c public server .1.3.6.1.4.1.2021.255 UCD-SNMP-MIB::ucdavis.255.1 = STRING: "life the universe and everything" UCD-SNMP-MIB::ucdavis.255.2.1 = INTEGER: 42 UCD-SNMP-MIB::ucdavis.255.2.2 = OID: SNMPv2-SMI::private.42.42.42 UCD-SNMP-MIB::ucdavis.255.2.3 = INTEGER: 21 UCD-SNMP-MIB::ucdavis.255.3 = Timeticks: (363136200) 42 days, 0:42:42.00 UCD-SNMP-MIB::ucdavis.255.4 = IpAddress: 127.0.0.1 UCD-SNMP-MIB::ucdavis.255.5 = Counter32: 42 UCD-SNMP-MIB::ucdavis.255.6 = Gauge32: 42
There were several issues with ssize_t in the passthrough code, which were expected to be fixed as of net-snmp-5.1.2. Please try net-snmp-5.1.2-4 or later.
Using net-snmp-5.1.2-6 I was unable to duplicate the problem (that is to say, it seems to work as expected). It also seems that it fixed bug#119688 for me as well (although I hadn't reported on it, I had noticed the problem with the 2.6 kernel series). Thanks for your efforts. -Doug