![snmpd 无法 statfs 目录](https://linux22.com/image/1140739/snmpd%20%E6%97%A0%E6%B3%95%20statfs%20%E7%9B%AE%E5%BD%95.png)
在 Ubuntu 16.04 上,我运行 snmpd 进行监控。在我的系统日志中,我每 5 分钟看到以下消息:
Sep 23 11:10:11 kvm snmpd[3427]: Cannot statfs /sys/kernel/debug/tracing: Permission denied
snmp 守护程序正在 snmp 用户下运行。/sys/kernel/debug 具有权限:
drwx------ 27 root root 0 Sep 22 21:34 .
所以,这个错误是有道理的。然而,不合理的是 snmpd 为何试图统计这个目录。有什么想法吗?
答案1
下面的设置在 中。当我从 更改为/etc/default/snmpd
时,权限被拒绝消息消失,因此我认为它与日志级别有关。Ls3d
Lsd
SNMPDOPTS='-Lsd -Lf /dev/null -u snmp -g snmp -I -smux,mteTrigger,mteTriggerConf -p /run/snmpd.pid'
我在 中找到了一些有关 snmpd 日志级别的信息ServerFault 上的这个问题。
答案2
这是一篇较旧的帖子,但它是 DuckDuckGo 上的第一篇,所以我要发布一个澄清,因为我整个上午都在研究这个问题。我正在运行带有 systemd 的 Debian 9,因此您需要按照前面所述/lib/systemd/system/snmpd.service
使用 进行编辑和重新加载systemctl daemon-reload
。您还需要使用 重新启动 snmpd systemctl restart snmpd
。您可以使用 检查用于实际启动服务的命令行systemctl status snmpd
。
-Lsd
上面关于更改为 的说明-Ls3d
是错误的。此选项区分大小写,-Ls3d
不执行任何操作。用于启动服务时也不会引发错误。正确的选项是-LS3d
。摘自手册页:
-Ls FACILITY
Log messages via syslog, using the specified facility ('d' for LOG_DAEMON, 'u' for
LOG_USER, or '0'-'7' for LOG_LOCAL0 through LOG_LOCAL7).
There are also "upper case" versions of each of these options, which allow the
corresponding logging mechanism to be restricted to certain priorities of message.
For -LF and -LS the priority specification comes before the file or facility token.