Comment 15 for bug 1918141

> I'm not sure it's *ever* correct for distribution packaging to ship After=network-online.target

you're correct, it's not. As you pointed out that upstream systemd recommends, what applications *should* do is handle interface configuration changes (e.g. carrier loss/gain), but few applications actually do that, as it's far easier to simply assume networking is 'already set up' from the application's POV.

> "my system hangs on boot because I'm booting offline"

indeed, and this is something that annoys me frequently, very commonly seen (for me at least) when my network configuration includes an interface that I know isn't currently connected during boot, and yet I have to stare at the boot progress waiting to timeout before it continues.

To clarify that point a bit, systemd-networkd itself doesn't block progress to multi-user.target; it only informs systemd-networkd-wait-online, which is what network-online.target waits for. There's a similar service for network-manager. And also, it's entirely possible to configure networkd to *not* block boot for any particular interface, using the RequiredForOnline= parameter (I'm not sure about anything equivalent for network-manager).

> This isn't a Ubuntu decision - upstream of the package/functionality goes this way

and this hits the core of the problem - few upstream applications really want to add the extra complexity of being able to dynamically handle networking. Which is generally fair, but depending on the exact application and the exact way it uses networking, it can sometimes be a problem.

> For this I honestly see no risks of regressions for nfs-server.

The only way this could possibly cause a regression is if nfs-server was the *only* (enabled) service on a user's system that included Wants=network-online.target. If *any* other service Wants=network-online.target (and *any* service also has After=network-online.target), then boot will wait for network-online.target, and it doesn't matter at all *how many* services want it, the timeout waiting for it is the same.

Note that cloud-config.service and cloud-final.service both depend on network-online.target, so *all* cloud images will block boot until network-online.target completes.

In a default Ubuntu install, there are various services that will block boot waiting for networking, most obviously whoopsie.service, which I believe is always installed by default, so again *all* Ubuntu installs will wait for network-online.target.

> Even more reason to seek to develop a best practice then, rather than continue to exacerbate a problem that might already exist.

The best practice would likely be to spend time working with individual applications so they could handle dynamic changes in networking better, but even then it needs to be a case-by-case basis for applications depending on network-online at boot. Additionally, unless we can remove the need for network-online.target from *all* services enabled on any particular machine, it won't help at all - only a single service pulling in network-online.target makes all other work pointless. Of course, simply working on getting all installed-by-default services to not require network-online.target would be a big benefit to boot speed in many cases.

Additionally, we could very likely improve things dramatically by using RequiredForOnline= more liberally, but that would require end-user knowledge of which interfaces aren't actually needed at boot. This is exposed in netplan with 'optional' but there seems to be no equivalent for network-manager.

Finally I'll note that applications cannot simply add After=network-online.target, they *must* also include Wants=network-online.target. You can see my details in bug 1912826 to see why both After= and Wants= are needed and how to easily reproduce the start-before-network-online issue if no services include Wants=network-online.target.