Hi Magnus, Thanks for your reply. I found the issue with locking and unlocking mechanism which my application is using. And by correcting it issue is no more available.
Thanks once again! Regards, Sagar. On 10/08/15 1:58 pm, "Magnus Fromreide" <ma...@lysator.liu.se> wrote: >On Tue, Jul 21, 2015 at 09:10:45AM +0000, Sagar Kapadi (sakapadi) wrote: >> Hi, >> >> This is Sagar Kapadi. >> I am using net-snmp5.7.2 stack on power PC architecture. Here we are >>trying to stress the traps. So we are sending a trap at every 50seconds >>of interval. >> >> I am hitting an issue where I have multiple trap-destinations >>configured. >> >> Initially netstat details are like below >> >> netstat nal|grep :705 >> tcp 0 0 127.0.0.1:705 0.0.0.0:* >>LISTEN >> tcp 0 0 127.0.0.1:705 127.0.0.1:47237 >>ESTABLISHED >> tcp 672 0 127.0.0.1:47237 127.0.0.1:705 >>ESTABLISHED >> >> But after 24 hours, connection between SNMPD and SNMP-SUBAGNETD which >>is on port 705 is going into CLOSE_WAIT state. >> I have collected the netstat details and strace output of SNMP-SUBAGENT >>process. Kindly check it below. >> >> Below is the netstat ouput after it went into CLOSE_WAIT state >> netstat nal|grep :705 >> tcp 0 0 127.0.0.1:705 0.0.0.0:* >>LISTEN >> tcp 96757 0 127.0.0.1:47237 127.0.0.1:705 >>CLOSE_WAIT >> >> Below is the strace output of SNMP-SUBAGENTD >> strace -p 26960 >> Process 26960 attached - interrupt to quit >> futex(0xfb8e83c, 0x80 /* FUTEX_??? */, 2 > >The futex system call on linux indicates that you are waiting for some >lock. > >You have not given enough information for me to tell anything beyond that. > >Is it possible for you to present a somewhat deeper stack trace, e.g. the >output of 'gdb -p 26960 -ex where --batch'? > >/MF ------------------------------------------------------------------------------ _______________________________________________ Net-snmp-coders mailing list Net-snmp-coders@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
