Re: No hrSWRunPath in HOST-RESOURCES-MIB

Kamil Kisiel <[email protected]>
Newsgroups gmane.network.net-snmp.user
Message-ID <C5F25831.8B66%[email protected]>
On 27/03/09 1:21 , "Dave Shield" <[email protected]> wrote:

> 2009/3/27 Mike Ayers <[email protected]>:
>>        Are you sure they're not deliberately eliding the data for security
>> reasons?
> 
> Even if they are blocking individual instances within the hrSWRunPath
> (which frankly, I doubt), that shouldn't break a walk of this object.
> Remember that an snmpget on selected individual instances (e.g.
> 4049 - cron) *does* work.   But snmpget on process 2 (kthreadd)
> returns noSuchInstance.
> 
> It feels suspiciously that this missing instance (whether deliberate or
> accidental) is causing the GETNEXT processing to move on to the next
> MIB object, rather than skipping this particular instance and returning
> the next.
> 
> Kamal,
>    can you please confirm whether
>       snmpgetnext    ...  hrSWRunPath.4048
>                  returns /usr/bin/cron  (as expected)
> 
> Also, what does
>       snmpgetnext  .... hrSWRunPath.2
>              return?
> 
> More generally, is the missing instance #2 an isolated example,
> one of a small handful of similar cases, or the norm?
> 
> The simplest approach is probably to walk one of the other columns
> in this table, and catch the output in a text file.   Then convert this
> file into a shell script, containing a sequence of "snmpget" commands
> on the specific hrSWRunPath instances.
>    OK - some of those will be transient processes, that will no longer
> be around when you run the snmpget script.  But it should be reasonably
> clear which hrSWRunPath instances ought to be present but are not.
> 
> What sort of patterns do you see?
> 
> Dave

I did some more poking and here is what I found.

snmpgetnext ... HrSWRunPath.4048

returns 

HOST-RESOURCES-MIB::hrSWRunPath.4049 = STRING: "/usr/sbin/cron"
 
as expected.

snmpgetnext ... HrSWRunPath.1 returns

HOST-RESOURCES-MIB::hrSWRunParameters.1 = ""

which is clearly not correct.

The pattern I've found is that this wrong behavior occurs with processes
that are kernel processes, those listed as "[process]" in ps output.





Notice of Confidentiality: The information transmitted is intended only for the
person or entity to which it is addressed and may contain confidential and/or
privileged material. Any review, re-transmission, dissemination or other use of
or taking of any action in reliance upon this information by persons or entities
other than the intended recipient is prohibited. If you received this in error
please contact the sender immediately by return electronic transmission and then
immediately delete this transmission including all attachments without copying,
distributing or disclosing the same.


------------------------------------------------------------------------------
_______________________________________________
Net-snmp-users mailing list
[email protected]
Please see the following page to unsubscribe or change other options:
https://lists.sourceforge.net/lists/listinfo/net-snmp-users
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.