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.
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.
This has missed 8.0 -- I'm moving it to 9.0 and assigning it to the default owner (Angus)
This seems like a fairly cosmetic issue. Is it causing any functional issues?
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.
According to our records, this should be resolved by openstack-tripleo-heat-templates-9.0.1-0.20181013060908.el7ost. This build is available now.
Couldn't reproduce the original bug. Not via manual run (snmpd -D -Lo TCP:1161 > /tmp/snmpd.debug.log1 2>&1) Or via systemctl start snmpd
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2019:0446