Description of problem: After HUP signal was sent to snmpd, snmpwalk returned the following error. % snmpwalk -v2c -c SECRET localhost hrStorageTable HOST-RESOURCES-MIB::hrStorageTable = No Such Object available on this agent at this OID skipNFSInHostResources is enabled in snmpd.conf and the following disk directives are in it. disk / 15% disk /var 10% disk /tmp 10% disk /opt 10% This problem happens upon the following conditions. 1) the last entry of /etc/mtab is NFS 2) no filesystem mounted on /opt, which is the last entry of disk directive 3) use the customer's snmpd.conf attached. 4) run this commands # snmpwalk -v2c -c SECRET localhost hrStorageTable # snmpget -v2c -c SECRET localhost hrStorageType.4 # pkill -HUP snmpd # snmpwalk -v2c -c SECRET localhost hrStorageTable Version-Release number of selected component (if applicable): net-snmp-5.3.2.2-9.el5_5.1 How reproducible: Always upon a condition above. Steps to Reproduce: See the procedure in "Description of problem" above Actual results: snmpwalk can output correct information. Expected results: snmpwalk cannot output correct information. Additional info: HRFS_entry always has a address returned by getmntent() or NULL in snmpd. When snmpwalk command finished without any problems, HRFS_entry becomes NULL, which is a last value returned by getmntent(). But, after a command is executed, there are some cases that HRFS_entry doesn't become NULL. A example is the snmpget command above. As another case, it happens also when a snmpwalk command ends on the way by timeout. The condition that HRFS_entry is not NULL is needed to reproduce it. So, above snmpget command is needed to reproduce this issue. When HUP signal is received, snmpd.conf is re-read. And, in the handler disk_parse_config() for "disk /opt", find_device() is called. find_device(char *path) ... while (NULL != (mntent = getmntent(mntfp))) ... It seems that getmnent() reuses the memory for /etc/mtab. So, getmntent() returns the same address as HRFS_entry. This means that the value of address 'HRFS_entry' is changed in every calls of this getmntent(). This while statement is called to find the filesystem mounted on /opt. When it doesn't exist, the last entry of /etc/mtab is set to HRFS_entry. In this case, it's a entry of NFS. And, with "snmpwalk -v2c -c sGnEmSp% localhost hrStorageTable", var_hrstore() is called. u_char * var_hrstore(struct variable *vp, oid * name, size_t * length, int exact, size_t * var_len, WriteMethod ** write_method) { ... if (HRFS_entry && netsnmp_ds_get_boolean(NETSNMP_DS_APPLICATION_ID, NETSNMP_DS_AGENT_SKIPNFSINHOSTRESOURCES) && Check_HR_FileSys_NFS()) return NULL; When HRFS_entry has a NFS entry, Check_HR_FileSys_NFS() returns 1. As a result, var_hrstore() returns NULL, which means that it can not find a expected value. Init_HR_FileSys() is called in var_hrstore() as below. var_hrstore() -> header_hrstoreEntry() -> Init_HR_Store() -> Init_HR_FileSys() <<===== here -> for(;;) { Get_Next_HR_Store() } -> Check_HR_FileSys_NFS() and return NULL It's called to (re)open /etc/mtab. I thought that HRFS_entry should be initialized in Init_HR_FileSys(). I created a patch for it, and I confirmed it fixed this problem. I will attach the patch on this buzilla.
I successfully reproduced the bug in my environment, thanks for detailed breakdown. I got a request which leads to hrStorageTable rewrite (see bug #595322) and the bug is not reproducible in my work-in-progress version. I also checked that HRFS_entry is set to NULL in Init_HR_FileSys() there, as your patch suggests, so the bug does not need any patch. I leave it open so our QA can check I am right.
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2011-1076.html