'\" t .\" Title: NetworkManager-wait-online.service .\" Author: .\" Generator: DocBook XSL Stylesheets vsnapshot .\" Date: 11/30/2022 .\" Manual: Network management daemons .\" Source: NetworkManager-wait-online.service 1.40.6 .\" Language: English .\" .TH "NETWORKMANAGER\-WAIT\-ONLINE\&" "8" "" "NetworkManager\-wait\-online\&" "Network management daemons" .\" ----------------------------------------------------------------- .\" * Define some portability stuff .\" ----------------------------------------------------------------- .\" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ .\" http://bugs.debian.org/507673 .\" http://lists.gnu.org/archive/html/groff/2009-02/msg00013.html .\" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ .ie \n(.g .ds Aq \(aq .el .ds Aq ' .\" ----------------------------------------------------------------- .\" * set default formatting .\" ----------------------------------------------------------------- .\" disable hyphenation .nh .\" disable justification (adjust text to left margin only) .ad l .\" ----------------------------------------------------------------- .\" * MAIN CONTENT STARTS HERE * .\" ----------------------------------------------------------------- .SH "NAME" NetworkManager-wait-online.service \- Wait for network to come online .SH "DESCRIPTION" .PP NetworkManager\-wait\-online\&.service delays network\-online\&.target until network is ready\&. .PP The systemd target network\-online\&.target acts as a synchronization point for services to start after network is configured\&. Such services should order themselves After=network\-online\&.target (and never After=NetworkManager\-wait\-online\&.service)\&. NetworkManager\-wait\-online\&.service is a one\-shot service that itself is ordered Before=network\-online\&.target and this way delays the target until the network is configured\&. .PP NetworkManager\-wait\-online\&.service itself is almost not configurable itself\&. Instead the connection profiles and configuration in NetworkManager affects the behavior\&. .PP In the best case, all services on the system can react to networking changes dynamically and no service orders itself after network\-online\&.target\&. That way, NetworkManager\-wait\-online\&.service has no effect and, for example, does not delay the boot\&. That means, if the problem is a long boot time related to NetworkManager\-wait\-online\&.service, a possible solution is to investigate the services that claim to require network and fix those\&. .PP For services that require network configured, NetworkManager\-wait\-online\&.service is the default implementation provided by NetworkManager to delay the target\&. But it does nothing magical\&. With special requirements, it may be sensible to disable NetworkManager\-wait\-online\&.service and replace it with a similar service that better implements the requirement\&. .PP NetworkManager\-wait\-online\&.service blocks until NetworkManager logs "startup complete" and announces startup complete on D\-Bus\&. How long that takes depends on the network and the NetworkManager configuration\&. If it takes longer than expected, then the reasons need to be investigated in NetworkManager\&. .PP There are various reasons what affects NetworkManager reaching "startup complete" and how long NetworkManager\-wait\-online\&.service blocks\&. .sp .RS 4 .ie n \{\ \h'-04'\(bu\h'+03'\c .\} .el \{\ .sp -1 .IP \(bu 2.3 .\} In general, startup complete is not reached as long as NetworkManager is busy activating a device and as long as there are profiles in activating state\&. During boot, NetworkManager starts autoactivating suitable profiles that are configured to autoconnect\&. If activation fails, NetworkManager might retry right away (depending on connection\&.autoconnect\-retries setting)\&. While trying and retrying, NetworkManager is busy until all profiles and devices either reached an activated or disconnected state and no further events are expected\&. Basically, as long as there are devices and connections in activating state visible with \fBnmcli device\fR and \fBnmcli connection\fR, startup is still pending\&. .RE .sp .RS 4 .ie n \{\ \h'-04'\(bu\h'+03'\c .\} .el \{\ .sp -1 .IP \(bu 2.3 .\} When a device reaches activated state, depends on its configuration\&. For example, with a profile with both IPv4 and IPv6 addressing enabled, the device is possibly considered fully activated when either of the address families is ready\&. This can be controlled with the ipv4\&.may\-fail and ipv6\&.may\-fail settings, to indicate that the address family is required\&. There are also ipv4\&.required\-timeout and ipv6\&.required\-timeout settings which affect how long to wait for an address family\&. Likewise, properties like ipv4\&.dhcp\-timeout and ipv6\&.ra\-timeout affect how long NetworkManager will try the IP configuration before giving up\&. .RE .sp .RS 4 .ie n \{\ \h'-04'\(bu\h'+03'\c .\} .el \{\ .sp -1 .IP \(bu 2.3 .\} For example, a bridge or bond profile cannot do IP configuration without ports\&. When booting with such profiles that autoactivate without ports, NetworkManager\-wait\-online\&.service blocks until timeout\&. This is a configuration error\&. .RE .sp .RS 4 .ie n \{\ \h'-04'\(bu\h'+03'\c .\} .el \{\ .sp -1 .IP \(bu 2.3 .\} Dispatcher scripts for the "pre\-up" event run at a late stage during activation of a profile\&. These scripts block the activation for when NetworkManager considers the profile fully activated\&. See also \fBNetworkManager-dispatcher\fR(8) for details\&. .RE .sp .RS 4 .ie n \{\ \h'-04'\(bu\h'+03'\c .\} .el \{\ .sp -1 .IP \(bu 2.3 .\} The connection property connection\&.wait\-activation\-delay also adds an additional delay during activation and delays startup complete\&. This is to workaround certain cases where a device is known to not be ready for a certain amount of time\&. .RE .sp .RS 4 .ie n \{\ \h'-04'\(bu\h'+03'\c .\} .el \{\ .sp -1 .IP \(bu 2.3 .\} The property connection\&.wait\-device\-timeout of the connection profiles waits until the waited devices appear\&. This is useful if the driver takes a longer time to detect the networking interfaces\&. Similar with the connection\&.gateway\-ping\-timeout property\&. .RE .sp .RS 4 .ie n \{\ \h'-04'\(bu\h'+03'\c .\} .el \{\ .sp -1 .IP \(bu 2.3 .\} With Wi\-Fi devices, NetworkManager needs to wait for the first scan result to know which networks might be available\&. That always adds a delay\&. .RE .sp .RS 4 .ie n \{\ \h'-04'\(bu\h'+03'\c .\} .el \{\ .sp -1 .IP \(bu 2.3 .\} With ethernet devices, NetworkManager waits for carrier until the configurable [device*]\&.carrier\-timeout is reached\&. This is because some devices take a long time to detect carrier and it means to boot with cable unplugged, will unnecessarily delay NetworkManager\-wait\-online\&.service\&. .RE .PP NetworkManager\-wait\-online\&.service internally uses nm\-online\&. .SH "BUGS" .PP Please report any bugs in NetworkManager at the \m[blue]\fBNetworkManager issue tracker\fR\m[]\&\s-2\u[1]\d\s+2\&. .SH "SEE ALSO" .PP \m[blue]\fBNetworkManager home page\fR\m[]\&\s-2\u[2]\d\s+2, \fBNetworkManager\fR(8), \fBnm-online\fR(1), .SH "NOTES" .IP " 1." 4 NetworkManager issue tracker .RS 4 \%https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues .RE .IP " 2." 4 NetworkManager home page .RS 4 \%https://networkmanager.dev .RE