1NETWORKMANAGER-WAIT-ONLINE(N8e)twork management daemoNnEsTWORKMANAGER-WAIT-ONLINE(8)
2
3
4
6 NetworkManager-wait-online.service - Wait for network to come online
7
9 NetworkManager-wait-online.service delays network-online.target until
10 network is ready.
11
12 The systemd target network-online.target acts as a synchronization
13 point for services to start after network is configured. Such services
14 should order themselves After=network-online.target (and never
15 After=NetworkManager-wait-online.service).
16 NetworkManager-wait-online.service is a one-shot service that itself is
17 ordered Before=network-online.target and this way delays the target
18 until the network is configured.
19
20 NetworkManager-wait-online.service itself is almost not configurable
21 itself. Instead the connection profiles and configuration in
22 NetworkManager affects the behavior.
23
24 In the best case, all services on the system can react to networking
25 changes dynamically and no service orders itself after
26 network-online.target. That way, NetworkManager-wait-online.service has
27 no effect and, for example, does not delay the boot. That means, if the
28 problem is a long boot time related to
29 NetworkManager-wait-online.service, a possible solution is to
30 investigate the services that claim to require network and fix those.
31
32 For services that require network configured,
33 NetworkManager-wait-online.service is the default implementation
34 provided by NetworkManager to delay the target. But it does nothing
35 magical. With special requirements, it may be sensible to disable
36 NetworkManager-wait-online.service and replace it with a similar
37 service that better implements the requirement.
38
39 NetworkManager-wait-online.service blocks until NetworkManager logs
40 "startup complete" and announces startup complete on D-Bus. How long
41 that takes depends on the network and the NetworkManager configuration.
42 If it takes longer than expected, then the reasons need to be
43 investigated in NetworkManager.
44
45 There are various reasons what affects NetworkManager reaching "startup
46 complete" and how long NetworkManager-wait-online.service blocks.
47
48 • In general, startup complete is not reached as long as
49 NetworkManager is busy activating a device and as long as there are
50 profiles in activating state. During boot, NetworkManager starts
51 autoactivating suitable profiles that are configured to
52 autoconnect. If activation fails, NetworkManager might retry right
53 away (depending on connection.autoconnect-retries setting). While
54 trying and retrying, NetworkManager is busy until all profiles and
55 devices either reached an activated or disconnected state and no
56 further events are expected.
57
58 Basically, as long as there are devices and connections in
59 activating state visible with nmcli device and nmcli connection,
60 startup is still pending.
61
62 • When a device reaches activated state, depends on its
63 configuration. For example, with a profile with both IPv4 and IPv6
64 addressing enabled, the device is possibly considered fully
65 activated when either of the address families is ready. This can be
66 controlled with the ipv4.may-fail and ipv6.may-fail settings, to
67 indicate that the address family is required. There are also
68 ipv4.required-timeout and ipv6.required-timeout settings which
69 affect how long to wait for an address family. Likewise, properties
70 like ipv4.dhcp-timeout and ipv6.ra-timeout affect how long
71 NetworkManager will try the IP configuration before giving up.
72
73 • For example, a bridge or bond profile cannot do IP configuration
74 without ports. When booting with such profiles that autoactivate
75 without ports, NetworkManager-wait-online.service blocks until
76 timeout. This is a configuration error.
77
78 • Dispatcher scripts for the "pre-up" event run at a late stage
79 during activation of a profile. These scripts block the activation
80 for when NetworkManager considers the profile fully activated. See
81 also NetworkManager-dispatcher(8) for details.
82
83 • The connection property connection.wait-activation-delay also adds
84 an additional delay during activation and delays startup complete.
85 This is to workaround certain cases where a device is known to not
86 be ready for a certain amount of time.
87
88 • The property connection.wait-device-timeout of the connection
89 profiles waits until the waited devices appear. This is useful if
90 the driver takes a longer time to detect the networking interfaces.
91 Similar with the connection.gateway-ping-timeout property.
92
93 • With Wi-Fi devices, NetworkManager needs to wait for the first scan
94 result to know which networks might be available. That always adds
95 a delay.
96
97 • With ethernet devices, NetworkManager waits for carrier until the
98 configurable [device*].carrier-timeout is reached. This is because
99 some devices take a long time to detect carrier and it means to
100 boot with cable unplugged, will unnecessarily delay
101 NetworkManager-wait-online.service.
102
103 NetworkManager-wait-online.service internally uses nm-online.
104
106 Please report any bugs in NetworkManager at the NetworkManager issue
107 tracker[1].
108
110 NetworkManager home page[2], NetworkManager(8), nm-online(1),
111
113 1. NetworkManager issue tracker
114 https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues
115
116 2. NetworkManager home page
117 https://networkmanager.dev
118
119
120
121NetworkManager-wait-online NETWORKMANAGER-WAIT-ONLINE(8)