Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
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:


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.