Michael Higgins wrote:
Robert Story wrote:
On Fri, 04 Mar 2005 10:46:02 -0800 Michael wrote:Thanks for the reply and suggestions. I can ignore SIGPIPE, but I'll also have to skip the close(2) call so that the trap handler can be started. I wonder what the effect of that might be?
MH> Using a simple setup as described in MH> http://www.net-snmp.org/tutorial/tutorial-5/commands/snmptrap.html, when MH> a trap is received, the snmptrapd process fails from a broken pipe. I MH> then use the same setup with 5.0.9 and everything functions as designed.
MH> MH> I did a little digging and it looks like the problem is in MH> agent/mibgroup/utilities/execute.c in run_exec_command(). I don't know MH> a whole lot about how this is architected, but it appears that two MH> threads are responsible for making this happen. One gets the trap MH> handler process running and the other writes to its stdin and waits for MH> any output.
MH> MH> What I see happening is the thread that is initiating the trap handler MH> does some manipulation of file descriptors, closing the standard ones MH> and redirecting them to pipes. When it does a close(2), this function MH> never returns. (Is this stderr?)
Yes, and it is odd that it doesn't return..
MH> In the meantime, the other thread MH> marches ahead and attempts to write to the pipe. This is where the MH> broken pipe happens and the process terminates.
Apparently snmpd handles this by ignoring SIGPIPE. Add this code in snmptrapd.c, near the other signal handlers:
#ifdef SIGPIPE signal(SIGPIPE, SIG_IGN); /* 'Inline' failure of wayward readers */ #endif MH> I didn't see it bugged either. Should it be?
Yes, anything that causes the daemon to crash is very bad.
Mike
I added the code to ignore the SIGPIPE signal and found that I also had to remove the close(2) to get to the execv() call that runs the trap handler. In the snmptrapd.conf file for 5.0.9 I had:
traphandle IF-MIB::linkDown "/home/mhiggins/src/snmp/traps.sh" linkDown traphandle IF-MIB::linkUp "/home/mhiggins/src/snmp/traps.sh" linkUp
This caused execv to fail with errno 2, no such file or directory. Thre must be an error in tokenize_exec_command() because it was return the command with the leading " still in place. When I changed the snmptrapd.conf to:
traphandle IF-MIB::linkDown /home/mhiggins/src/snmp/traps.sh linkDown traphandle IF-MIB::linkUp /home/mhiggins/src/snmp/traps.sh linkUp
The trap handler completed successfully. I'll look into that to see I can find a fix. Now the only thing left at the moment is a formatting issue. I have some OID values that are getting a linefeed erroneously added at some point. I'm suspecting realloc_format_trap() in apps/snmptrapd_log.c. I'll look at that too.
Thanks again for the suggestion. Any idea if removing close(2) might have some sort of side effect? When I figure out the other two items I'll submit a bug with suggested fixes.
-- Mike
------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Net-snmp-users mailing list Net-snmp-users@lists.sourceforge.net Please see the following page to unsubscribe or change other options: https://lists.sourceforge.net/lists/listinfo/net-snmp-users
