snmpd starts before the network stack is fully online (network.target vs network-online.target)
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
net-snmp (Ubuntu) |
Fix Released
|
Low
|
Unassigned |
Bug Description
Sometimes snmpd starts too early in the bootprocess and cannot resolve hostnames in the access control part of the configuration.
This might be related to the dependencies of the snmpd systemd-unit.
Seems like snmpd should depend on network-
Logging output:
sebastian.
...
Sep 4 03:07:54 hostname snmpd[736]: /etc/snmp/
Sep 4 03:07:54 hostname snmpd[736]: net-snmp: 1 error(s) in config file(s)
...
snmpd.conf:
sebastian.
rocommunity COMMUNITY HOSTNAME .1
rwcommunity COMMUNITY HOSTNAME
...
relevant part of the systemd-unit:
sebastian.
After=network.
sebastian.
Ubuntu Release / Package Version:
snmpd Package 5.7.3+dfsg-5ubuntu5 on Ubuntu 19.10
snmpd Package 5.8+dfsg-2ubuntu2.3 on Ubuntu 20.04.1 LTS
Please note that this has been confirmed as a bug and was fixed in RedHat Packages of net-snmp:
https:/
https:/
Related branches
- Bryce Harrington (community): Approve
- git-ubuntu import: Pending requested
- Canonical Server: Pending requested
-
Diff: 1293 lines (+1065/-3)4 files modifieddebian/changelog (+1021/-0)
debian/control (+3/-2)
debian/rules (+5/-1)
debian/source.apport (+36/-0)
Changed in net-snmp (Ubuntu): | |
status: | New → Triaged |
tags: | added: server-next |
Changed in net-snmp (Ubuntu): | |
importance: | Undecided → Low |
tags: | removed: server-next |
tags: | added: network-online-ordering |
Changed in net-snmp (Ubuntu): | |
assignee: | Sergio Durigan Junior (sergiodj) → nobody |
status: | In Progress → Triaged |
Hello Sebastian and thanks for this bug report.
I think think your analysis is correct, however in my understanding the only issue caused by this bug consists in logged error messages that could be avoided if snmpd waited for network- online. target. Can you please confirm this is the case?
The bug is valid in any case, however its importance may affect how and where it's best to fix it. For example, if the the issue is purely cosmetic (dirty logs), then it's probably best to report it in Debian; Ubuntu and other distributions derived by Debian will then pick up the fix in the next releases. Otherwise, if the bug affects the functionality of the package, we'll probably want to fix it directly in Ubuntu.