Closed mcian2 closed 1 year ago
Hi @mcian2 - I've just released version 3.9.3 of the npm, which allows you troubleshoot this scenario further by subscribing to a close
event on the subagent's TCP socket like this:
subagent.on("close", function() {
// do whatever you want here
console.log ("Subagent socket closed");
});
In your case, a "No Such Object" error is being returned by the master agent, which indicates that it doesn't have that OID registered to the subagent any more.
Logging the aforementioned close
event in combination with examining a packet capture between master and subagent would be able to determine if it was:
(a) your subagent code inadvertently unregistering the OID,
(b) a bug in the library incorrectly unregistering the OID from the subagent side, or
(c) your master agent losing the OID registration separately from any subagent interaction e.g. through restarting
If I was a betting man, my money would be on (c).
Thanks Mark,
I will try this out soon-ish :-)
Ian
Upgrading from 3.5.2 to 3.9.3 has resolved this problem.
Thanks again Mark Ian
Thanks for the update @mcian2. With version 3.5.2 being a couple of years old, there is a chance of this being a bug that has been fixed in the intervening period. Closing as resolved.
Hi folks,
This isn't necessarily an issue but more of a question:
I have a react app that implements a subagent. It works fine on my dev platform, able to handle hundreds of snmpwalk requests without problem. However when installed on a production platform (which is only slightly more loaded, but still, both systems lower than 6% cpu), the subagent will soon stop processing requests. Snmpwalk queries produce "No Such Object available on this agent at this OID". Restarting the app resolves the problem but only temporarily.
Has anyone else experienced anything similar? Is there some event I could listen for in order to somehow reset the registration?
Thanks!
entry: "./src/app.tsx"
` app.tsx:
agent.ts: