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.
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
No response in 6 months, closing this bug as works for me. Read ya, Phil