> If there is no network [1] to connect to (if network interface is down [2])
> NetworkManager will make "nm-online -s" stop [3] without waiting.
[1] we usually talk about connection profiles or devices/interfaces
[2] it would be better to say, if no suitable profile is ready to
autoconnect.
[3] `nm-online -s` waits until NetworkManager declares "startup
complete" reached.
I find the wording of the comment not very clear or useful.
Possibly I don't understand it properly, but that is a problem
for a comment that is supposed to help.
Remove it.
We encountered the following situation:
* nm-online (NetworkManager-wait-online.service) is started
* NetworkManager tries to configure network
* the first try of using dhclient fails with timeout for some reasons
* the second try of running dhclient completes successfully (NMs tries himself)
We get a working network, but it takes more that 30 seconds.
NetworkManager-wait-online.service fails, it may be a false negative
to checkers of network being online. It will also be a false positive signal
to start mounting network (CIFS, NFS etc.) shares, for example, because
they depend from network-online.target and network-online.target will become
reached right after NetworkManager-wait-online.service fails.
So, it makes sense to increase default timeout from 30 to 60 seconds.
@thaller wrote in https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/237
that there may be cases where, for example, incorrectly set up bridges
or just network may lead to delays when booting the system.
Yes, but:
* if there is no possibility to start trying to connect the network, e.g. if all network interfaces,
managed by NetworkManager, are DOWN, NM will not try to connect network and "nm-online -s" will
exit with 0 without waiting (so, this will not prolong start up of workstations or servers
when ethernet cable is just not plugged in)
* an additional potential 30 seconds delay seems to be less harmful then a false positive to start
mounting network shares or doing abything else too eraly, when an additional wait for a few seconds
would have prevented those things from failing.
All things considered, it seems reasonable to increase this timeout from 30 seconds to 1 minute (60 seconds).
Signed-off-by: Mikhail Novosyolov <m.novosyolov@rosalinux.ru>
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/675
`systemctl start network-online.target` should suffice to start
"NetworkManager.service".
That would work because
- "network-online.target" has "Wants=NetworkManager-wait-online.service"
- "NetworkManager-wait-online.service" has "Require=NetworkManager.service".
But previously, "NetworkManager-wait-online.service" would just
fail with missing dependency.
See also https://github.com/systemd/systemd/pull/6065 which does the
same for networkd's wait-online serice, and see rh#1452866 for a
use-case.
Related: https://bugzilla.redhat.com/show_bug.cgi?id=1452866
network.target is a very early boot target which basically says "I can start
opening sockets now". It has nothing to do with being connected to the internet
and is often required by early boot services as well.
Drop the unnecessary and wrong Wants=/Before=network.target to avoid dependency
cycles and boot delays.
https://bugzilla.gnome.org/show_bug.cgi?id=746039https://launchpad.net/1430280
systemd's new network-online target abstracts the "wait until
networking is up" stuff, and NM-wait-online implements that
functionality. Thus NM-wait-online should be ordered before
(and thus be a dependency of) network-online.
Since commit 0ce4b6b412
NetworkManager-wait-online.service quits immediately if there is no link yet.
Fix it by removing the '-x' option.
But if we do just that, NM-w-o would add a useless 30 seconds delay in the
case when NM is not running at all.
Solve this by adding a Requisite= dependency on NM.
https://bugzilla.redhat.com/show_bug.cgi?id=710502
1) Don't require NM, but run after it. This allows this service
to be installed without bringing up NetworkManager. Add -x so that
it exits if NM isn't running.
2) Install as a want of network.target, instead of multi-user.target.
This allows us to skip it if nothing requires network.target or the
legacy $network SysV capability.
This pulls in network.target from NetworkManager.service (and not the
other way round), as suggested and agreed on on the systemd ML:
http://lists.freedesktop.org/archives/systemd-devel/2011-March/001692.html
This also introduces an auxiliary service
NetworkManager-wait-online.service that can be used to order a unit
after the point where the network is available. When this is enabled
with "systemd enable NetworkManager-wait-online.service" the unit
network.target will be delayed until the network is up, which is
suitable for synchronizing NFS mounts and similar to it.
https://bugzilla.redhat.com/show_bug.cgi?id=692008
