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 can hit any time, not just in shutdown. At bootup, when suspending, etc. This message and the wait time is so bad. Systemd basically implemented Windows Update waitouts on Linux! It’s incredible!
Switching from systemd to sysvinit solved that pretty nicely.
You didn’t solve the problem. You only ignored it. Systemd does exactly what it’s instructed to do. If a program takes longer it waits if it’s instructed to do so. It’s well defined and predictable. Much better than a random assortment of bash scripts. And it’s incredibly customizable. If the defaults don’t fit you, you can easily override them without touching the main unit itself.
Oh no, I solved the problem: I uninstalled systemd. It’s systemd who is ignoring things, such as the longstanding history of Unix and Linux (research what happened between systemd and screen, tmux, dtach).
I don’t think that’s true. Bootup and suspending don’t need stopping things like that.
Source: I use systemd btw
Oh but it’s not just stopping things, starting things is subject to the same issue also:
A start job is running for "wait for network to be available"(attached to a network interface that is not necessarily connected at bootup)
Systemd is just special.
https://askubuntu.com/questions/972215/a-start-job-is-running-for-wait-for-network-to-be-configured-ubuntu-server-17-1
nowadays most network interfaces ship that config option by default
Well I guess that tells you everything.
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.