Bug 1275730 - snmpd repeatedly logs errors for "Cannot statfs net:[###...#]"
snmpd repeatedly logs errors for "Cannot statfs net:[###...#]"
Status: NEW
Product: Red Hat OpenStack
Classification: Red Hat
Component: rhosp-director (Show other bugs)
7.0 (Kilo)
x86_64 Linux
low Severity medium
: Upstream M2
: ---
Assigned To: Pradeep Kilambi
Shai Revivo
: Triaged
Depends On:
  Show dependency treegraph
Reported: 2015-10-27 11:10 EDT by Peter Portante
Modified: 2018-06-13 22:01 EDT (History)
16 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Peter Portante 2015-10-27 11:10:23 EDT
Looks snmpd periodically logs errors of the form:

  Cannot statfs net:[4026532907]#012: No such file or directory

This seems to be caused by these two mount entries:

  proc on /run/netns/qdhcp-f90899a0-dc73-45c6-9889-80473cf67336 type proc (rw,nosuid,nodev,noexec,relatime)
  proc on /run/netns/qdhcp-f90899a0-dc73-45c6-9889-80473cf67336 type proc (rw,nosuid,nodev,noexec,relatime)

If one runs "snmpd -D -Lo -f > /tmp/snmpd.debug.log 2>&1", killing it after about 10 seconds (be patient, it does not take ctrl-c right away), you find in the log entries like:

  trace: _fsys_type(): hardware/fsys/fsys_mntent.c, 73:
  fsys:type: Classifying proc
  Cannot statfs net:[4026532907]
  : No such file or directory
  trace: netsnmp_fsys_by_path(): hardware/fsys/hw_fsys.c, 154:
  fsys:path: Get filesystem entry (net:[4026532907])

These seem to match up with the two mount entries.
Comment 2 Peter Portante 2015-10-27 12:02:49 EDT
The reason this is filed against the OSP director is that my RHEL 7.1 host was installed a running with SNMPD prior to the openstack install.

After running, "openstack undercloud install", SNMPD was started and the error messages begin.
Comment 9 Hugh Brock 2016-03-21 07:33:47 EDT
This has missed 8.0 -- I'm moving it to 9.0 and assigning it to the default owner (Angus)
Comment 12 Ben Nemec 2017-03-09 18:30:02 EST
This seems like a fairly cosmetic issue.  Is it causing any functional issues?
Comment 13 Peter Portante 2017-03-09 22:49:34 EST
It does not appear to be a functional issue.  But neither is it cosmetic, since depending on the configuration, you can see lots of these logs logged by snmpd at an error level.

This affects common logging efforts, as the more noise our products emit, the harder it is to wade through that noise to find real errors.

Adding Tushar to comment.

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