Bill, I couldn't see the issue that I have reported in the latest version NetSNMP [v 5.7.1]. On first look into snmpd v 5.7.1 debug log, I could see changes happening in the suspected area.
Change noticed in v5.7.1 debug log compared to v5.6.pre3: The delegated session after SET_UNDO is processed and then the session is REMOVED. Also "SET request complete" message is seen in the log. And so, the subsequent requests are not queued at the master agent side. I am a beginner in this application and do comment based on the debug messages. So not in a position to confirm whether the issue is really fixed in v 5.7.1. Also I have seen some of the similar issues that you have reported under "Error handling path in agentx master and subagents" in net-snmp 5.7.1 So I think probably some guys actually taking part in the core work behind NetSNMP application suit development and maintenance can comment authentically like whether the two ideas that you have suggested will fix the issue or like net-snmp 5.7.1 have done a fix on this already. thank you, -renjith .-----Original Message----- .From: Bill Fenner [mailto:fen...@gmail.com] .Sent: 29 December 2011 07:15 PM .To: Renjith R. V. .Cc: net-snmp-coders@lists.sourceforge.net .Subject: Re: agentx master agent not responding after an agentx subagent .SET timeout . .Renjith, . .Could it be easy as adding something like . .if (asp == netsmp_processing_set) { . DEBUGMSGTL(("snmp_agent", "SET request abandoned, asp = %8p\n", . asp)); . netsnmp_processing_set = NULL; .} . .to free_agent_snmp_session()? . .It only rarely happens for me in my test environment, and it sounds .like you have a straightforward replication case, so maybe you could .test this idea? . .Another idea is to change the calling sequence altogether: replace .netsnmp_free_agent_snmp_session_by_session() with .netsnmp_wrap_up_request( netsnmp_agent_snmp_session_by_session( .sess .), SNMP_ERR_GENERR ) - that would get the user a response to their .request too. . .Thanks, . Bill . .On Tue, Dec 27, 2011 at 11:54 PM, Renjith R. V. .<renjith...@nestgroup.net> wrote: .> Yes. the sub agent is getting disconnected from the master during this .> failure scenario. And the sub agent hit with SIGPIPE in between. .> .> Please refer the debug log attached below. .> .> .> .> agent_set: did set mode = 2, status = 0 .> .> agentx/subagent: checking status of session 0x90b5588 .> .> agentx_build: packet built okay .> .> agentx/subagent: handling agentx request (req=0x5,trans=0x2,sess=0x5) .> .> agentx/subagent: -> undoset .> .> agentx/subagent: handling agentx subagent set response .> (mode=162,req=0x4,trans=0x2,sess=0x5) .> .> agentx_build: packet built okay .> .> [My Agent] sig_hndlr() ============> SIGPIPE hit .> .> agentx/subagent: FINISHED .> .> agentx/subagent: transport disconnect indication .> .> agentx/subagent: unregistering callbacks for session 0x90b5588 .> .> agent_set: doing set mode = 5 (SET_UNDO) .> .> .> .> Looking at the master agent debug log, I have one more observation like it .> seems after returning from SET_UNDO operation, snmp-agent delegate the .> session, unload the subagent registered mibs and remove the agentx .session. .> But the previously delegated session is not processing further. And the .> print "snmp_agent: SET request complete" [as got in SET_COMMIT scenario] .is .> not seen. So I think as you stated in your bug, netsnmp_processing_set is .> not cleared in this path causing further request queued. .> .> .> .> [Note: NET-SNMP version: 5.6.pre3] .> .> .> .> -renjith .> .> .> .> From: Bill Fenner [mailto:fen...@gmail.com] .> Sent: 27 December 2011 07:18 PM .> To: Renjith R. V. .> Cc: <net-snmp-coders@lists.sourceforge.net> .> Subject: Re: agentx master agent not responding after an agentx subagent .SET .> timeout .> .> .> .> Hi Renjith, .> .> .> .> I came across this behavior in a different context and filed a .> .bug: http://sourceforge.net/tracker/?func=detail&aid=3456337&group_id=12 .694&atid=112694 .> ("Certain agentx failures can result in apparent agent hang"). I was unaware .> of the "set times out" way to get into this state - please add your findings .> to this bug. .> .> .> .> Did you ever see the subagent getting disconnected from the master agent? .> Does that explain the two different behaviors that you saw? .> .> .> .> Bill .> .> .> .> .> On Dec 27, 2011, at 4:48 AM, "Renjith R. V." <renjith...@nestgroup.net> .> wrote: .> .> I am using snmpd as the agentx master and a sub agent is running as the .> agentx client. .> I have a scenario in which one parameter SET operation[handler running .> in sub agent] will take more time to complete. .> It is observed from snmpd debug log that the operation, SET_ACTION .> timeout at master side at this time. .> .> The issue starts from here. The subsequent GET calls to master agent .> doesn't get any reply. .> Even the SNMP contact from the MIB browser itself is not getting. .> SNMP dump shows that the agent is getting the message but it doesn't .> send any response. .> Further debug log analysis showed the subsequent requests are queued at .> master agent side. .> "snmp_agent: request queued while processing set, asp = 0x840cf40" .> And this issue continues for all further GET operations that I have .> tried. .> .> Do I need to handle anything more to address this delayed SET_ACTION .> return from subagent handler? .> Or Do I need to configure some parameters to avoid this situation? .> Can anybody support to sort out this issue? .> .> One more observation: .> During the issue reported case, master agent send SET_UNDO command .after .> SET_ACTION timeout. .> Sometimes (rarely) I could see that master agent send SET_FREE command .> after SET_ACTION timeout. .> The later case, subsequent GET calls (eg:- sysUpTime) are properly .> processed by master agent and I am getting proper response. .> ***** Confidentiality Statement/Disclaimer ***** .> .> This message and any attachments is intended for the sole use of the .> intended recipient. It may contain confidential information. Any .> unauthorized use, dissemination or modification is strictly prohibited. If .> you are not the intended recipient, please notify the sender immediately .> then delete it from all your systems, and do not copy, use or print. .> Internet communications are not secure and it is the responsibility of the .> recipient to make sure that it is virus/malicious code exempt. .> The company/sender cannot be responsible for any unauthorized .alterations or .> modifications made to the contents. If you require any form of confirmation .> of the contents, please contact the company/sender. The company/sender .is .> not liable for any errors or omissions in the content of this message. .> .> ------------------------------------------------------------------------------ .> Write once. Port to many. .> Get the SDK and tools to simplify cross-platform app development. Create .> new or port existing apps to sell to consumers worldwide. Explore the .> Intel AppUpSM program developer opportunity. .appdeveloper.intel.com/join .> http://p.sf.net/sfu/intel-appdev .> _______________________________________________ .> Net-snmp-coders mailing list .> Net-snmp-coders@lists.sourceforge.net .> https://lists.sourceforge.net/lists/listinfo/net-snmp-coders .> .> .> ***** Confidentiality Statement/Disclaimer ***** .> .> This message and any attachments is intended for the sole use of the .> intended recipient. It may contain confidential information. Any .> unauthorized use, dissemination or modification is strictly prohibited. If .> you are not the intended recipient, please notify the sender immediately .> then delete it from all your systems, and do not copy, use or print. .> Internet communications are not secure and it is the responsibility of the .> recipient to make sure that it is virus/malicious code exempt. .> The company/sender cannot be responsible for any unauthorized .alterations or .> modifications made to the contents. If you require any form of confirmation .> of the contents, please contact the company/sender. The company/sender .is .> not liable for any errors or omissions in the content of this message. ***** Confidentiality Statement/Disclaimer ***** This message and any attachments is intended for the sole use of the intended recipient. It may contain confidential information. Any unauthorized use, dissemination or modification is strictly prohibited. If you are not the intended recipient, please notify the sender immediately then delete it from all your systems, and do not copy, use or print. Internet communications are not secure and it is the responsibility of the recipient to make sure that it is virus/malicious code exempt. The company/sender cannot be responsible for any unauthorized alterations or modifications made to the contents. If you require any form of confirmation of the contents, please contact the company/sender. The company/sender is not liable for any errors or omissions in the content of this message. ------------------------------------------------------------------------------ Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox _______________________________________________ Net-snmp-coders mailing list Net-snmp-coders@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
