[ net-snmp-Bugs-1506707 ] newer than 5.0.8: EXEC wrong order!

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 454-5900

Bugs item #1506707, was opened at 2006-06-15 15:37
Message generated for change (Comment added) made by dts12
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=112694&aid=1506707&group_id=12694

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Ryan Pavely (sirparadox)
Assigned to: Nobody/Anonymous (nobody)
Summary: newer than 5.0.8: EXEC wrong order!

Initial Comment:
I recently upgraded my farm of 30+ servers from
Net-Snmp-5.0.8 to 5.3.0.1, and even tried 5.2.2.  Any
suggestions before I try all archived versions?

FreeBSD 6.1

It took me a day to notice but my stats were all wrong
from the exec commands.  What it seems to do is put the
last one first when you have more then 6 exec commands.  

Sometimes it even does worse and sorts them all wrong.

Here is my /usr/local/share/snmp/snmpd.conf
Server:~# cat /usr/local/share/snmp/snmpd.conf | grep
-v "^#" | grep -v "^$"
syslocation  Oct
syscontact  root
rocommunity  #############################
disk /
disk /tmp
disk /usr
disk /var
disk /var/log
disk /var/qmail
disk /var/qmail/queue
load  2 2 2
master  agentx
exec A /usr/bin/true A
exec B /usr/bin/true B
exec C /usr/bin/true C
exec D /usr/bin/true D
exec E /usr/bin/true E
exec F /usr/bin/true F

==========
 snmp walk it....

Client:~# snmpwalk -v2c -c ### Server  
.1.3.6.1.4.1.2021.8.1.3
UCD-SNMP-MIB::extCommand.1 = STRING: /usr/bin/true A
UCD-SNMP-MIB::extCommand.2 = STRING: /usr/bin/true B
UCD-SNMP-MIB::extCommand.3 = STRING: /usr/bin/true C
UCD-SNMP-MIB::extCommand.4 = STRING: /usr/bin/true D
UCD-SNMP-MIB::extCommand.5 = STRING: /usr/bin/true E
UCD-SNMP-MIB::extCommand.6 = STRING: /usr/bin/true F

==========

Now... Add another line to the conf
exec H /usr/bin/true H

Client:~# snmpwalk -v2c -c ### server 
.1.3.6.1.4.1.2021.8.1.3
UCD-SNMP-MIB::extCommand.1 = STRING: /usr/bin/true D
UCD-SNMP-MIB::extCommand.2 = STRING: /usr/bin/true B
UCD-SNMP-MIB::extCommand.3 = STRING: /usr/bin/true C
UCD-SNMP-MIB::extCommand.4 = STRING: /usr/bin/true A
UCD-SNMP-MIB::extCommand.5 = STRING: /usr/bin/true E
UCD-SNMP-MIB::extCommand.6 = STRING: /usr/bin/true F
UCD-SNMP-MIB::extCommand.7 = STRING: /usr/bin/true G

=======

Now.. Lets really see some fun.. Add
exec I /usr/bin/true I 
exec J /usr/bin/true J 
exec K /usr/bin/true K 

Client:~# snmpwalk -v2c -c ### server 
.1.3.6.1.4.1.2021.8.1.3
UCD-SNMP-MIB::extCommand.1 = STRING: /usr/bin/true K
UCD-SNMP-MIB::extCommand.2 = STRING: /usr/bin/true B
UCD-SNMP-MIB::extCommand.3 = STRING: /usr/bin/true C
UCD-SNMP-MIB::extCommand.4 = STRING: /usr/bin/true A
UCD-SNMP-MIB::extCommand.5 = STRING: /usr/bin/true E
UCD-SNMP-MIB::extCommand.6 = STRING: /usr/bin/true F
UCD-SNMP-MIB::extCommand.7 = STRING: /usr/bin/true G
UCD-SNMP-MIB::extCommand.8 = STRING: /usr/bin/true D
UCD-SNMP-MIB::extCommand.9 = STRING: /usr/bin/true H
UCD-SNMP-MIB::extCommand.10 = STRING: /usr/bin/true I
UCD-SNMP-MIB::extCommand.11 = STRING: /usr/bin/true J

----------------------------------------------------------------------

>Comment By: Dave Shield (dts12)
Date: 2006-07-26 12:33

Message:
Logged In: YES 
user_id=88893

OK - found the underlying problem.

The last block in the routine "extensible_parse_config()"
(starting "if (scount > 1)") is only relevant to relocatable
entries.  Applying it to entries in the main extTable can
have unpredictable results.

You can fix the problem by moving this code within the scope
of the previous block ("if (ptmp->miblen > 0)") - just move
the closing brace to come after the "scount>1" block.

I've updated the 5.2.x, 5.3.x and main branches accordingly.

----------------------------------------------------------------------

Comment By: Dave Shield (dts12)
Date: 2006-07-26 10:24

Message:
Logged In: YES 
user_id=88893

OK - I've now managed to reproduce this problem.
It doesn't affect Linux systems - it seems to be specific to
FreeBSD (maybe other *BSD systems as well - I still need to
check that).

One quick workaround - try configuring using
   --with-out-mib-modules=ucd-snmp/extensible

The "extend" module includes a compatability mode to support
the old "exec" format as well, and this *does* report things
in the correct order.  It's not perfect - I've just spotted
that it omits the command-line parameters from extCommand
output.  But it might be useable nevertheless.

I'll try and track down the underlying problem ASAP.

Dave

----------------------------------------------------------------------

Comment By: Ryan Pavely (sirparadox)
Date: 2006-06-21 19:03

Message:
Logged In: YES 
user_id=853291

Tested Exec sorting on as many versions as I could on
FreeBSD 6.0 --with-mib-modules="ucd-snmp/diskio" does not

net-snmp-5.0.8: Exec Works, diskio does not
net-snmp-5.0.11: Exec works, diskio does not
net-snmp-5.1.3.1: Exec does not sort properly, diskio works
net-snmp-5.1.4: Exec does not sort properly, diskio works
net-snmp-5.2.2: Exec does not sort properly, diskio works
net-snmp-5.3.0.1: Exec does not sort properly, diskio works

I thought long and hard about switching to Extend and it's
truly a large scale project to convert 100+ machines and
database structure for this.  I will fire up my favorite C
editor and hope for the best that I can personally find the
sorting malfunction to EXEC intraduced sometime after 5.0.11.

----------------------------------------------------------------------

Comment By: Thomas Anders (tanders)
Date: 2006-06-15 16:53

Message:
Logged In: YES 
user_id=848638

As for snmpd crashing w/ "extend", please retry with
5.3.1.rc1 and file a separate bug (with gdb backtrace) if
you can reproduce it. ASAP, please, as we're getting ready
to release 5.3.1. Thanks in advance.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2006-06-15 16:23

Message:
Logged In: NO 

I tried extend.  It would be nice to not have to rely on
'order' on my oid's however I have a few problems.

1. A TON of systems and databases would have to be changed
for the new oid's
2. I tried extend and it seems I am not getting output
3. Once I loaded up all 23 of my extend commands which are
very simple 'cat log file for a few lines, grab a number and
return' and snmpd likes to crash now :)

And ideas when this bug might get some time to be fixed?

----------------------------------------------------------------------

Comment By: Thomas Anders (tanders)
Date: 2006-06-15 15:43

Message:
Logged In: YES 
user_id=848638

Weird. I'd suggest you look into "extend" which provides a
better framework for those extension scripts and does not
suffer from this. Is this a feasible workaround for you for
the moment?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=112694&aid=1506707&group_id=12694