Marmorstein, Robert writes:
NetworkManager-wait-online is to make sure that remote drives mount
AFTER an IP address has been configured:
That's exactly the use case that's broken here.
By the way, my own experiments (on a lab of twenty-five FC26 workstations
dynamic IP addresses) seem to confirm that removing -s fixes the issue.
the timeout from 30 to 45 was enough to keep switch NetworkManager-wait-
from timing out due to switch glitchiness.
So, getting rid of -s fixes network connections that use dhcp, perhaps in
combination with an increased timeout. But getting rid of -s definitely
breaks static IP connections even worse than they are already broken. With
the default configuration with the -s option, the IP addresses are not
assigned for about 1-2 seconds until after nm-online returns, based on the
data that I collected over the last week; and without the -s options nm-
online returns 5-6 seconds before my script succeeds in binding the static
IP address. With the -s option you have a fighting chance of booting a
functional server with static IP addresses. Without the -s option you're
pretty much are assured of a farked boot, with all services that bind to
specific IP addresses failing to start (except for openssh whose service
file has an explicit retry interval).
Just to add to this clusterfracas: systemd itself has a timeout for starting
jobs. Looks like if you try to increase the timeout to more than 90 seconds,
it won't work. This is buried in the man pages. systemd.service(5) documents
that the default value for TimeoutStartSec comes from DefaultTimeoutStartSec
"from the manager configuration file", which must mean something that's
buried in /etc/NetworkManager. I don't see it set anywhere which must mean,
according to systemd-system.conf(5) that it takes its hardcoded default of
So, looks like we're going to have to throw both NetworkManager and systemd
into a cage ring. Fight to the death. Whoever comes out, gets to set the