☰

systemd：自定义 snmpd .so 代理随机能够并且无法在 /etc/snmp/ 下写入自定义信息

tag-icon • tag-icon systemd
systemd：自定义 snmpd .so 代理随机能够并且无法在 /etc/snmp/ 下写入自定义信息

我为 snmpd 创建了一个动态可加载对象 .so 代理。该代理负责响应 oid 空间中的某些查询。该代理将安全信息写入 /etc/snmpd/custom_sec.conf 下。一切正常，但有一个奇怪的问题。

大约 50% 的系统启动时一切正常。我可以正常更改 custom_sec.conf。但另外 50% 的启动时，snmpd 或我的 .so 或 systemd 进入奇怪的状态，文件写入被拒绝。我无法写入文件。我甚至无法从我的 .so 写入简单的调试文件。

如果我执行 systemctl restart snmpd，无论启动条件如何，一切都会正常工作。

如果我对 snmpd.service 进行以下更改，则一切都正常：

[Unit]
Description=Simple Network Management Protocol (SNMP) Daemon.
# After=network.target ### CHANGED THIS TO FOLLOWING:
After=multi-user.target
ConditionPathExists=/etc/snmp/snmpd.conf

[Service]
Environment="MIBSDIR=/usr/share/snmp/mibs:/usr/share/snmp/mibs/iana:/usr/share/snmp/mibs/ietf:/usr/share/mibs/site:/usr/share/s\
nmp/mibs:/usr/share/mibs/iana:/usr/share/mibs/ietf:/usr/share/mibs/netsnmp"
Environment="MIBS="
Type=simple
ExecStartPre=/bin/mkdir -p /var/run/agentx
ExecStart=/usr/sbin/snmpd -Lsd -Lf /dev/null -u Debian-snmp -g Debian-snmp -I -smux,mteTrigger,mteTriggerConf -f
ExecReload=/bin/kill -HUP $MAINPID
Restart=always
RestartSec=1s

[Install]
# WantedBy=multi-user.target ### CHANGED THIS TO FOLLOWING:
WantedBy=graphical.target

似乎我不是唯一一个面临此类问题的人，例如：Systemd 服务无法写入文件，但仅限于冷启动时

有人能告诉我为什么我所做的唯一更改是推迟 snmpd 的启动，而我总是可以写入文件吗？

编辑 2022-03-24 6:44

遗憾的是我需要 10 点声誉才能发布图片，但这里是 systemd 启动图：

http://m.asuka.fi/uploads/startup_order_nonworking.svg

http://m.asuka.fi/uploads/startup_order_working.svg

令我困惑的是，在 startup_order_working.svg 中 snmpd 根本看不见……

编辑 2022-03-24 11:16

有一段时间，我把注意力集中在目标上。我认为我需要在 systemd-user-sessions.service 之后运行 snmpd.service 。但我又回到了 After=multi-user.target / WantedBy=graphical.target 解决方案。这是唯一有效的方法。这是 systemd、snmpd 还是两者的 bug？

答案1

我找到了问题所在。最后发现这很平凡。

我的 .so 也与 mosquitto 交互，但代理大多数时候在 snmpd/.so 之后启动。我的代码没有检查 mosquitto_connect() 是否真的成功。因此实际上没有任何入站 MQTT 消息被发送。这些消息会指示 .so 更改 /etc/snmp/ 下的安全文件。但什么都没有发送，也没有到达任何日志记录/printf 行。

我修改了 snmpd.service 如下：

[Unit]
After=network.target mosquitto.service

现在每次都能正常工作。如果 .so 无法连接到 MQTT 代理，我可能应该让 snmpd 退出。但现在它可以正常工作了。

答案2

它可能是ld.so.cache由生成的文件ldconfig.service。
查看sudo systemctl edit ldconfig.service --full哪个刚刚运行ldconfig -X以重建ld.so.cache文件。

以下是一些您可以检查的事项。

创建一个包含上次启动时间轴的 svg 文件（已加载服务的时间轴）。网络浏览器应该能够读取该文件（比控制台更好）。

systemd-analyze plot > boot.svg

安慰

systemd-analyze blame

正在sudo ldconfig -v展示您的.so？
需要多长时间才能完成？

相关内容