Sam Varshavchik writes:
a well-defined point when the system boots, then, I guess we can
reach the
conclusion that NetworkManager is totally incapable of accomplishing basic
networking administration tasks, and move on to consider ugly hacks like
https://github.com/svarshavchik/unfrak-systemd-network to be the only way to
And to close the loop on this dumpster fire, the evidence is in:
NetworkManager-wait-online does not really wait until anything is online.
Got solid proof, right here. I just installed and tested the unfrak-systemd-
network script on that server of mine where things often don't get started
properly. This script quickly tries to bind to the server's known IP
addresses, logs the results, and tries every second until it succeeds, then
E-mails me the report.
Well, on this particular boot, which succeeded,
NetworkManagerWaitOnline.service alleged "Started" on 08:35:33:
Dec 18 08:35:27
shorty.email-scan.com systemd[1]: Starting Network Manager Wait
Dec 18 08:35:33
shorty.email-scan.com systemd[1]: Started Network Manager Wait O
unfrak-systemd-network ran a second later:
Dec 18 08:35:33
shorty.email-scan.com systemd[1]: Starting Unfrak systemd networ
Dec 18 08:35:35
shorty.email-scan.com systemd[1]: Started Unfrak systemd network
And the emailed report from the script landed in my mailbox:
Subject: systemd network initialization unfrak report
Message-ID: <courier.000000005A37C427.0000058D(a)www.courier-mta.com>
Date: Mon, 18 Dec 2017 08:35:35 -0500
--------------------------------------------------------------------------------
Time IP addresses
======== ==================
08:35:34
08:35:35 192.168.0.1
At 08:35:34 the server had no IP addresses, a full second until
NetworkManager assured the rest of the system that it's "online". Finally,
192.168.0.1 came up a second later.
This service is keyed to run after NetworkManager-wait-line:
[Unit]
Description=Unfrak systemd network startup
After=NetworkManager-wait-online.service systemd-networkd-wait-online.service
Before=network-online.target
Now that unfrak-systemd-network injects itself into the dependency chain,
and delays it, looks like all the problematic services get delayed until the
IP addresses are really there:
Dec 18 08:35:35
shorty.email-scan.com systemd[1]: Starting Privoxy Web Proxy Wit
Dec 18 08:35:36
shorty.email-scan.com systemd[1]: Started Privoxy Web Proxy With
Dec 18 08:35:35
shorty.email-scan.com systemd[1]: Starting Courier SOCKS 5 proxy
Dec 18 08:35:35
shorty.email-scan.com systemd[1]: Started Courier SOCKS 5 proxy.
It's a sad, sad state of affairs when one needs to resort to these kinds of
hacks just to get a server booted correctly.