Bug 85987 - ucd-snmp agent dies after 3-4 hours of continuous SNMP queries
Summary: ucd-snmp agent dies after 3-4 hours of continuous SNMP queries
Keywords:
Status: CLOSED WORKSFORME
Alias: None
Product: Red Hat Enterprise Linux 2.1
Classification: Red Hat
Component: ucd-snmp
Version: 2.1
Hardware: i686
OS: Linux
high
high
Target Milestone: ---
Assignee: Phil Knirsch
QA Contact: Brock Organ
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2003-03-11 22:09 UTC by Jai S. Arun
Modified: 2015-03-05 01:12 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2004-01-12 13:07:16 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Jai S. Arun 2003-03-11 22:09:57 UTC
Description of problem:
I have a ucd-snmp (ucd-snmp-4.2.4-1) agent running on  Red Hat Linux Advanced
Server release 2.1AS/i686 (Pensacola) kernel 2.4.9-e.3

Our product (IBM Load Balancer) has snmp query functionality which interfaced
thru smux subagent called "dpid". The dpi sub-agent dpid connects to ucd-snmp
agent and successfully interfaces with IBM Load Balancer to get the snmp queries.

We are trying to run a script on AIX to fetch the SNMP variables from the system
simply by snmp-walk, which runs continuously. The script commands are as following:
  while true;
  do
     date;
     snmpinfo -m dump -v -h hostname oid;
     sleep 1;
     done;

After 3-4 hours of continuous run the ucd-snmp agent dies abruptly there is no
core file produced and no conspicous trace logged in ucd-snmp agent log which
shows something trackable. The last lines of snmp agent log were:

2003-03-10 17:27:30 dumpv_send:                                                
                       ObjID:
enterprises.2.6.144.1.2.1.4.1.14.8.116.117.101.99.104.105.108.100.23.7.110.100.115.101.114.118.55
2003-03-10 17:27:30 trace: snmp_build_var_op(): snmp.c, 220
2003-03-10 17:27:30 dumph_send:                                                
                    Value
2003-03-10 17:27:30 dumpx_send:                                                
                     05 00
2003-03-10 17:27:30 dumpv_send:                                                
                       NULL
2003-03-10 17:27:30 trace: smux_snmp_process(): smux/smux.c, 1128
2003-03-10 17:27:30 smux: [smux_snmp_process] oid from build:
enterprises.2.6.144.1.2.1.4.1.14.8.116.117.101.99.104.105.108.100.23.7.110.100.115.101.114.118.55
2003-03-10 17:27:30 trace: smux_snmp_process(): smux/smux.c, 1136
2003-03-10 17:27:30 smux: [smux_snmp_process] Sent 161 request to peer; 60 bytes
2003-03-10 17:27:30 trace: smux_snmp_process(): smux/smux.c, 1151
2003-03-10 17:27:30 smux: [smux_snmp_process] Peeked at 55 bytes
2003-03-10 17:27:30 dumpx_smux_snmp_process:                                   
                                A2 35 02 03 01 E3 63 02 01 00 02 01 00 30 28 30
26 06 21 2B 06 01 04 01 02 06 81 10 01 02 01 04
01 0E 08 74 75 65 63 68 69 6C 64 17 07 6E 64 73
65 72 76 38 02 01 0A
2003-03-10 17:27:30 dumpv_smux_snmp_process:                                   
                                trace: smux_snmp_process(): smux/smux.c, 1176
2003-03-10 17:27:30 smux: [smux_snmp_process] Received 55 bytes
2003-03-10 17:27:30 dumpx_recv:                                                
                   02 03 01 E3 63
2003-03-10 17:27:30 dumpv_recv:                                                
                     Integer:123747 (0x1E363)
2003-03-10 17:27:30 dumpx_recv:                                                
                   02 01 00
2003-03-10 17:27:30 dumpv_recv:                                                
                     Integer:0 (0x00)
2003-03-10 17:27:30 dumpx_recv:                                                
                   02 01 00
2003-03-10 17:27:30 dumpv_recv:                                                
                     Integer:0 (0x00)
2003-03-10 17:27:30 trace: smux_parse(): smux/smux.c, 1238
2003-03-10 17:27:30 smux: [smux_parse] Message type 2, reqid 123747, errstat 0,
        errindex 0

The dpi subagent fails to connect to ucd-snmp agent because its dies abruptly
and dpi log keep showing:

snmpdpi/dpid/src/dpid_main.c(427): rc=-1 from SMUXconnect()
snmpdpi/dpid/src/dpid_main.c(428) Connect to agent failed, will retry
snmpdpi/dpid/src/dpid_main.c(1008): select returned 0 fds
snmpdpi/dpid/src/dpid_main.c(427): rc=-1 from SMUXconnect()
snmpdpi/dpid/src/dpid_main.c(428) Connect to agent failed, will retry


Version-Release number of selected component (if applicable):
ucd-snmp-4.2.4-1

How reproducible:
Every Time

Steps to Reproduce:
1. snmpd -d -l /tmp/ucd-snmp.log
2. start dpi deamon (dpid2 -d 255)
3. start product subagent interface (subagent start)
4. run the script for snmp query

    
Actual results:
The ucd-snmp agent dies after 3-4 hours of continuous run of the snmp queries
script.

Expected results:
It should not die abruptly, atleast it should log in the log file if there is
any problem and what was  the cause made it to die.

Additional info:
We are in System Verification Test Phase of our product (IBM Load Balancer) and
this bug is blocking our SVT Exit. We want a fix for this problem ASAP.

Comment 1 Phil Knirsch 2003-07-31 16:28:29 UTC
We currently have a new ucd-snmp errata in the queue for the next quarterly
update. Unfortunaltely it hasn't passed our QA yet, but you can grab the
unsupported binaries here:

http://people.redhat.com/pknirsch/

The 7.2 binaries have been reported to work on AS2.1, so if you could give them
a shot and see if they work that would be great.

Read ya, Phil

Comment 2 Phil Knirsch 2004-01-12 13:07:16 UTC
No response in 6 months, closing this bug as works for me.

Read ya, Phil


Note You need to log in before you can comment on or make changes to this bug.