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