Closed Firefishy closed 7 months ago
Are we deliberately enabling wait-online or is something else enabling it? It's not normally needed...
Are we deliberately enabling wait-online or is something else enabling it? It's not normally needed...
We don't deliberately enable it, it is part of the dependency for some systemd services. Any service which depends on systemd-networkd
will trigger systemd-networkd-wait-online
. eg: systemd-resolved triggers it, but likely others too.
This shaves for around 90 seconds per test that is using networking: apache2, exim, etc.
We don't deliberately enable it, it is part of the dependency for some systemd services. Any service which depends on
systemd-networkd
will triggersystemd-networkd-wait-online
. eg: systemd-resolved triggers it, but likely others too.
No that's not how it works... There's a discussion at https://systemd.io/NETWORK_ONLINE/ but the important thing is that if a unit is configured to order itself after network-online.target
then you will need a service like systemd-networkd-wait-online.service
that can trigger it but the general recommendation is to write services so that don't need the network to be online (partly because nobody can agree what that means) and just order after network.target
instead so I was interested in what was waiting on network-online.target
which should itself be the only thing waiting on the networkd service.
This lets
systemd-networkd
think it is managing the networking in podman / docker and ensures thatsystemd-networkd-wait-online
does not wait for timeout on systemd services which rely on networking.