Since a few weeks, gdm was no longer starting right ahead. It was waiting for network-online.target to be finished. I figured out that it was due to yubihsm-connector.service (at least the problem went away when I purged the package): it marks itself "After=network-online.target" and as "WantedBy=multi-user.target". I'm not exactly sure how that ends up being in the dependency tree of gdm however... but I question the need of network-online.target. This is a daemon, it doesn't need outbound access, I assume "After=network.target" should be sufficient.
Looks like this comes from upstream. I agree network-online.target isn't necessary for the default and common case where you're just listening on 127.0.0.1. I think using network.target would be a problem if you set a different listen address in yubihsm-connector.yaml, though; Go doesn't seem to do IP_FREEBIND. I guess we could patch it to use network.target and add a comment to say that you might need to change that if you use a different listen address? And either way, I don't think I see a justification for Wants=systemd-networkd-wait-online.service - that unit has Before=network-online.target, so specifying it explicitly seems redundant.
Right. It might not be a good idea to change that in that case. I wonder if I just misdiagnosed the issue... because I don't see why gdm would have to wait for yubihsm-connector.service to start. At least not more specifically than nginx.service that I also run. I had no delay after removing it but maybe it's just that NetworkManager is behaving differently again after the last upgrade, or some slight difference in my networking environment (I do have an external dock that provides an ethernet interface that seems to have some issues from time to time). Ack. Cheers,
Hi Colin, thanks for pointing me at this issue. Installing yubihsm-connector on a system and then rebooting it may cause it to become "degraded" according to systemd. Let me detail how. In theorey ifupdown and networkd can cooperate as long as the user does not configure any interfaces in both tools at the same time. A problem arises when you try operating networkd without configuring any interfaces. systemd-networkd-wait-online only considers the system as connected when an interface managed by networkd gains a default route. If you don't configure any interfaces with it, that never happens and the unit times out. Hence it is a good idea to not enable networkd unless you actually manage a routed interface with it. I argue that service units should not impose a decision on what network management tool is in use. As you say, when networkd is enabled, systemd-networkd-wait-online.service is also enabled and orders before network-online.target, so yubihsm-connector.service will be fine even without wanting systemd-networkd-wait-online.service. Dropping the Wants is not a full solution to Rapahel's original problem, but it seems like it is part of the solution and significantly improves another niche case. Would you agree that this bears sufficiently significant benefits to try getting this change into trixie? I also researched other packages: https://codesearch.debian.net/search?q=Wants.*%3D.*systemd-networkd-wait-online&literal=0 * openfortivpn: unit not installed * waagent: unit not installed * atuin: unit installed outside search path Helmut
PS: I'm mildly confused that this bug, probably because it's cloned, wasn't forwarded to me, the principle Maintainer; unlike in the team maintenance situation, where it's clear Uploaders don't receive emails (#397761).