On Fri, Dec 30, 2011 at 12:41 AM, Renjith R. V.
<renjith...@nestgroup.net> wrote:
> I couldn't see the issue that I have reported in the latest version NetSNMP
> [v 5.7.1].
That's too bad. I have been doing all of my experiments with 5.7.1,
so I'm pretty sure the bugs are still present, maybe just harder to
invoke.
I decided to try to get to the core of this, and wrote a subagent with
a single scalar integer, whose set action is:
case MODE_SET_ACTION:
if (*requests->requestvb->val.integer == 0) {
/* unclean exit */
exit( 0 );
} else {
/* blocking sleep */
sleep( *requests->requestvb->val.integer );
}
to make it easy to test the two failure cases in agentx/master.c
("handle protocol disconnect" and "subagent request timeout"). (I'm
not completely sure that the sleep will work, as the ping protocol may
turn that into a disconnect; I may have to do something like
examples/delayed_instance.c so that the subagent keeps responding to
pings but doesn't respond to the pending request, but I figured I'd
try the easy thing first).
Bill
> 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
