Dear Robert,
Thank you for response.
RSTORY> That is definitely not the right solution, as it will unconditionally remove
RSTORY> all delegated requests for all sessions.
Yes... I know.
WSK> 3. what did I do to solve this problem ?
WSK> a. I removed following two lines from file agent/snmp_agent.c
RSTORY> That is definitely not the right solution, as it will unconditionally remove
RSTORY> all delegated requests for all sessions.
I know it is not a right solution. But, 'removing all delegated requests for all
sessions' is
better than 'no more response from snmpd'.
This 'no more response from snmpd' impacts not only request to removed sub-agent's
variables, but also impacts requests to master agent's variables or requests to other
sub-agent's variables.
For example, in my system, variable 'sysLocation.0' resides in master agent. But, when
this locking-problem occurs(because of removing one of sub agent), I also can not
get/set 'sysLocation.0'
In other words, when this locking problem occur, my snmpd can not do any kind of
snmp operation (get, set, what ever) with all mib variables. Only one remedy to
this problem is 'kill the snmpd process, and restart it'
RSTORY> Which is exactly what I would expect you fix to do.
I want a more reasonable solution for this locking problem. As you pointed out above,
my current solution ('removing two line') is not right solution. And, I also not sure,
my current solution prevents locking problem in 100%.
I eagerly want a solution. Because, in my system, locked snmpd is worse than
snmpd crash.
For your convenience, once more I describe my locking problem.
1. our system have more than two sub-agents.
2. there are many set requests to sub-agents.
3. shutdown interface between master agent and a sub-agent
4. above shutdown causes timeout in master agent, so master agent will call
close_agentx_session() with the sub-agent which located over the interface.
5. sometimes (randomly) master agent do not work any more (no more response)
but, in this status, master agent is not in infinite-loop, nor crash.
6. if there is no interface shutdown, my agentX system is fine with many many
snmp get/set requests.
RSTORY> What version are you using? If it isn't 5.1.2, can you reproduce the problem
RSTORY> with 5.1.2?
Our net-snmp version is 5.1.2.
This problem occurs since net-snmp v5.0.8 (I did not test with the version prior to
v5.0.8)
I used net-snmp more than two years. And, I used agentX feature from last year.
In the beginning, agentX feature had several problems. but, the fruit of many people's
efforts, current agentX feature in net-snmp is very robust and memory safe.
Finally, I only have following two problems in my net-snmp agentX system.
1. above locking problem
2. during MIB registration of sub-agent to master agent, if I shutdown interface
between
master agent and sub-agent, sometimes, sub-agent crash. (very rarely happen)
And, problem #1 is more serious than problem #2 for me.
I will wait a good news from you.
Thank you a lot for response again.
Best regards,
Won-Sik
----- Original Message -----
From: "Robert Story (Coders)" <[EMAIL PROTECTED]>
To: "Won-Sik Kim" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Friday, September 10, 2004 6:30 AM
Subject: Re: SNMP locking up problem
On Sun, 5 Sep 2004 18:10:18 +0900 Won-Sik wrote:
WSK> 1. which kind of locking ?
WSK> a. Every snmp get/set/getnext pdu to snmpd are discarded.
WSK> b. But, snmpd shows no problem with processing any signal.
WSK> c. It looks like main loop is also OK.
WSK> d. I am sure that snmpd is not in infinite loop status when this
WSK> problem occur.
WSK>
WSK> 2. when this problem occur ?
WSK> a. send a lot of snmpset pdu periodically to sub-agent 'A'. (I think
WSK> this item is necessary
WSK> to make this problem)
WSK> [...]
WSK> c. do 'link down' and 'link up' between master agent and sub-agent 'A'
WSK> continuously.
RSTORY> When a snmpset is received, the agent will not process any new requests until
RSTORY> the set finishes processing. If AgentX sessions are closed, then an outstanding
RSTORY> set request that is not cleaned up would definitely behave as you describe in
1.
WSK> 3. what did I do to solve this problem ?
WSK> a. I removed following two lines from file agent/snmp_agent.c
RSTORY> That is definitely not the right solution, as it will unconditionally remove
RSTORY> all delegated requests for all sessions.
WSK> b. because of removing two lines above, it seems, locking problem is
WSK> solved.
WSK> but, this solution causes all delegated snmp set requests to any
WSK> sub-agent return error when one of sub-agent disconnected. but,
WSK> this new small bug is much better than SNMP locking problem.
RSTORY> Which is exactly what I would expect you fix to do.
WSK> So, is there somebody who has any idea about my SNMP locking problem ?
RSTORY> What version are you using? If it isn't 5.1.2, can you reproduce the problem
RSTORY> with 5.1.2?
--
Robert Story; NET-SNMP Junkie <http://www.net-snmp.org/>
<irc://irc.freenode.net/#net-snmp>
Archive: <http://sourceforge.net/mailarchive/forum.php?forum=net-snmp-coders>
You are lost in a twisty maze of little standards, all different.
