Hi list, I use net-snmp 5.4.2.1 (on SLES 11 SP1) with agentx to monitor GPFS (v3.4) distributed filesystems.
This works by running a gpfs snmp agentx daemon on one of the gpfs nodes. Usually, I can snmpwalk starting at oid gpfsDiskStatus and get a correct list of the status of all disks on all nodes. But for one node the agent delivers wrong results after disks of one node have failed and got repaired. (I only show one disk per node. The other disks show the same behaviour) GPFS-MIB::gpfsDiskStatus."data"."down"."data06node19" = STRING: "unknown" GPFS-MIB::gpfsDiskStatus."data"."hddpool"."data06node17" = STRING: "InUse" GPFS-MIB::gpfsDiskStatus."data"."hddpool"."data06node18" = STRING: "InUse" As you can see, the oid of the repaired node contains "down" instead of the disk pool name. I verified with strace the gpfs snmp agentx daemon (on node17) recieves the correct status "InUse" for node19 disks. I guess, it cannot deliver that becaues the oid is wrong (contains "down" instead of "hddpool"). Of course I restarted all gpfs daemons, the gpfs agentx daemon, snmpd: no change. On other installations I already had disk problems and repaired them. The snmp disk status then was always correct. I couldnt find any files that contain the wrong oids - not on the snmpd side and not on the gpfs side. So my question is: How does the oid registration work with the agentx protocol? Is there some caching of oids involved that I overlooked? Maybe someone had a similar problem and solved this already? BR, Joachim ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb _______________________________________________ Net-snmp-users mailing list Net-snmp-users@lists.sourceforge.net Please see the following page to unsubscribe or change other options: https://lists.sourceforge.net/lists/listinfo/net-snmp-users
