snmpd starts before the network stack is fully online (network.target vs network-online.target)

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.

Hello Paride,

thank you for your evaluation of the bug report. I'll try to give you all the facts to support the process.

In our case the bug is not purely cosmetic. We restrict access for the read-only community for SNMPv2 in our snmpd.conf to a source host. The host is defined as a hostname, which is a valid way to specify SOURCE, according the snmpd.conf manpage:
...
       rocommunity COMMUNITY [SOURCE [OID | -V VIEW [CONTEXT]]]
...
      A restricted source can either be a specific hostname (or address), or a subnet
...

When snmpd is unable to resolve hostnames at daemon startup, the daemon keeps running but our configured source host is unable to do SNMP requests (which leads to unknowns in our monitoring stack, but that's just the consequence of the bug...). Only a restart (reload may be sufficient as well) of the daemon when the network is up fixes the problem.

FWIW, I submitted the following MR to Debian's net-snmp:

https://salsa.debian.org/debian/net-snmp/-/merge_requests/11

I agree with Paride here that it's better to fix this bug there.

Hiya! Is there any update on this, Sergio? :D

This is a low priority bug, and I believe it should be addressed in Debian first. For that reason, we're still waiting to see what Debian replies. On top of this, we have to consider that this bug is part of a much bigger discussion on how to properly implement network ordering when starting systemd services without resorting to "Wants=network-online.target", so I believe it will be some time before we see real progress here.

This bug was fixed in the package net-snmp - 5.9.1+dfsg-4ubuntu1

---------------
net-snmp (5.9.1+dfsg-4ubuntu1) kinetic; urgency=medium

  * Merge with Debian unstable (LP: #1971295, #1894190). Remaining changes:
    - Add apport hook:
      + d/control: add dh-apport to Build-Depends
      + d/rules: install the apport hook via debhelper
      + d/source.apport: apport hook
  * Dropped changes:
    - d/p/lp1945960-*: backport patches for the OpenSSL3 transition
      (LP #1945960)
    [ Included in 5.9.1+dfsg-3 ]
    - d/p/lp1969623-net-snmp-create-v3-user-Fix-the-snmpd.conf-path.patch:
      Set ${datarootdir} value in net-snmp-create-v3-user and fix
      error when creating user. (LP #1969623)
    [ Included in 5.9.1+dfsg-3 ]
    - d/control: Build-Depend on libsensors4-dev.
    [ Unnecessary; libsensors4-dev is a dummy transitional package to
      libsensors-dev ]

 -- Sergio Durigan Junior <email address hidden> Mon, 13 Jun 2022 17:36:01 -0400