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
------------------------------------------------------------------------------
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
