Transcript:
Two panel meme.
Top panel: Woman in the front seat of a car screaming at a child in the rear seat. She’s saying “Why can’t you just shutdown?”
Bottom panel: A child screaming “A stop job is running for Session c2 of user … (1:30 / no limit)”
That’s absolutely systemd’s fault. In any Linux system the only network interface that can (more or less) always trusted to be available and complete a full initialization sequence is
loAbsolutely nothing else.(The worse if you happen to have a WiFi that autoconnects but does it across the same SSID to different endpoints, but that one is wpa_supplicant’s fault if I’m not mistaken. Systemd just makes it worse)
It depends on whether you’re a server or PC. For PCs (as in personal computing) I agree systemd-networkd-wait-online.service should be disabled. For servers, I think it’s plausible that you require a network to be at all meaningful, especially if there’s some sort of database.
Eh, the only kind of server that I think you absolutely need full networking (address, iptables, routing, maybe even DNS) to be “meaningful” would be a database replica. Anything else, there is full use to partial network configuration: anything small enough that lets in a network connection someone else can use to diagnose (eg.: you can have a server that can spin up a meaningful session with only address and netmask, not routing).
That said, I’ve never seen a server, with or without systemd, set to wait for all possible network interfaces that are present to be fully configured… would me emotional murder with something like wireguard that by necessity has a depends on another interface’s routing. Usually with just
loplus any one available interface, it tends to suffice.Depends on how the network services are designed/configured.
If the service is allowed to just bind ‘::’, then generally, sure, start it up and more proper networking bringup can happen asynchronously.
But folks often have it bind a specific address/interface, in which case those binds will error and cause the service to error because it was asked to bind to something it could not. This is the use case I think the online target is designed to take the race conditions out of. It’s not that the service is not really useful without networking, it’s that the service will exit with error if the networking isn’t exactly as expected.
Of course, in this world of genericizing things around the worst cases, they end up blocking everything just in case, because they have no idea of the user has done something like make the service only work through one interface.