Bug 676669 - snmpwalk for hrStorageTable doesn't return correct information after receiving HUP signal
Summary: snmpwalk for hrStorageTable doesn't return correct information after receivin...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: net-snmp
Version: 5.6
Hardware: All
OS: Linux
medium
medium
Target Milestone: rc
: ---
Assignee: Jan Safranek
QA Contact: BaseOS QE Security Team
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-02-10 16:59 UTC by Masahiro Matsuya
Modified: 2018-11-14 15:59 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-07-21 09:11:26 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2011:1076 0 normal SHIPPED_LIVE net-snmp bug fix and enhancement update 2011-07-21 09:07:58 UTC

Description Masahiro Matsuya 2011-02-10 16:59:02 UTC
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.

Comment 3 Jan Safranek 2011-02-15 12:50:28 UTC
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.

Comment 9 errata-xmlrpc 2011-07-21 09:11:26 UTC
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

Comment 10 errata-xmlrpc 2011-07-21 12:27:51 UTC
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


Note You need to log in before you can comment on or make changes to this bug.