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=12694&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.
------------------------------------------------------------------------------
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
