Comment 2 for bug 1619258

Which services in snappy actually stall/wait on network-online.target? On my yakkety desktop system these are just rc-local.service, kerneloops.service, and lxd.service -- neither of which are really required to log into the device or start services (even ssh.service doesn't block on network-online.target).

So not implementing network-online.target would be a workaround, but I believe eventually this would not help -- as services which *legitimately* need to wait until the network is up (such as network mounts, backup software, etc.) would then unnecessarily fail.

I believe it is a more robust design to always let network-online.target do its job but avoid depending on it in services which don't really require network.

Can you please copy&paste the output of "systemctl list-jobs" when this happens? This should show the bits that wait on network-online.target.

> netplan should make the system check the physical link status when trying to bring up a network device instead of stalling the boot.

Both networkd and NM already do this -- they bring up an interface once it appears and gets a carrier. However, s-n-wait-online waits until all configured links appear (with a timeout of 2 minutes), which is usually what you want with services that depend on network-online.

So I believe completely disabling wait-online is not the right way. We might want to add syntax and functionality to mark devices like "allow-hotplug" in ifupdown, though.