2011-04-06 04:30:02 +02:00
|
|
|
[Unit]
|
|
|
|
|
Description=Network Manager Wait Online
|
2023-06-07 16:26:56 +02:00
|
|
|
Documentation=man:NetworkManager-wait-online.service(8)
|
2017-11-02 15:14:18 +01:00
|
|
|
Requires=NetworkManager.service
|
2011-05-10 16:34:11 -05:00
|
|
|
After=NetworkManager.service
|
2015-03-11 16:28:34 +01:00
|
|
|
Before=network-online.target
|
2011-04-06 04:30:02 +02:00
|
|
|
|
|
|
|
|
[Service]
|
2020-04-28 22:12:21 +02:00
|
|
|
# `nm-online -s` waits until the point when NetworkManager logs
|
|
|
|
|
# "startup complete". That is when startup actions are settled and
|
|
|
|
|
# devices and profiles reached a conclusive activated or deactivated
|
|
|
|
|
# state. It depends on which profiles are configured to autoconnect and
|
|
|
|
|
# also depends on profile settings like ipv4.may-fail/ipv6.may-fail,
|
|
|
|
|
# which affect when a profile is considered fully activated.
|
|
|
|
|
# Check NetworkManager logs to find out why wait-online takes a certain
|
|
|
|
|
# time.
|
|
|
|
|
|
2011-04-06 04:30:02 +02:00
|
|
|
Type=oneshot
|
2020-04-28 22:12:21 +02:00
|
|
|
ExecStart=@bindir@/nm-online -s -q
|
2016-06-02 17:58:35 +02:00
|
|
|
RemainAfterExit=yes
|
2011-04-06 04:30:02 +02:00
|
|
|
|
2020-04-28 22:12:21 +02:00
|
|
|
# Set $NM_ONLINE_TIMEOUT variable for timeout in seconds.
|
|
|
|
|
# Edit with `systemctl edit NetworkManager-wait-online`.
|
|
|
|
|
#
|
|
|
|
|
# Note, this timeout should commonly not be reached. If your boot
|
|
|
|
|
# gets delayed too long, then the solution is usually not to decrease
|
|
|
|
|
# the timeout, but to fix your setup so that the connected state
|
|
|
|
|
# gets reached earlier.
|
systemd: increase default timeout of NetworkManager-wait-online
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
2020-11-09 16:12:32 +03:00
|
|
|
Environment=NM_ONLINE_TIMEOUT=60
|
2020-04-28 22:12:21 +02:00
|
|
|
|
2011-04-06 04:30:02 +02:00
|
|
|
[Install]
|
2015-03-11 16:25:54 +01:00
|
|
|
WantedBy=network-online.target
|
