Justin Moore writes:
I interpret "-s" to mean "all interfaces are active
but do not necessarily
have an address or a default route". This means that NM will return success
What does it mean for an interface that has a static IP address explicitly
specified in its ifcfg file to be "active", but not have that IP address?
The problem with the former is that it can return before your system
can
reach the outside world (e.g., interface is up but doesn't have a DHCP-
The interface in question has a static IP address. DHCP is not in the
picture.
But an argument can be made that even if a network interface is configured
via DHCP, then it's not "active" until it succeeds in acquiring an IP
address. But that's besides the point, because these are simple, garden
variety, static IP addresses. Can be any simpler than that.
Furthermore, I distinctly recall incidents where something got fubared with
my DHCP server, and I had to drink a cup of coffee before other servers
finished booting.
It's been my experience that NetworkManager most definitely puts the brakes
on booting the server if dhclient can't get an IP address.
So, given that it throws a tantrum if dhclient can't get an IP address, I'm
quite puzzled that it also just blows past an network port with a static IP
address, but before it is fully configured with that IP address. This does
not compute.
assigned address). The problem with the latter is that if your system
has
multiple interfaces, as soon as *one* of them has an address and a route, NM
says all is well and continues, *even if that interface can't reach the
That's not how the nm-online man page describes the -s option. If that's not
what the -s option does, then I have no idea what it's supposed to be doing.
along before my actual network interface got an address. This caused
issues
with various services, and -- if you check the mythtv-users archives --
you'll see that the systemd people's response was "working as intended,
that's a bug in mythtv and the other pieces of software which don't adapt to
network interfaces which appear and disappear randomly."
Well, I wouldn't really expect any less flippant or arrogant response there,
this does not surprise me. But that's not important.
What is important, is that it's an inescapable conclusion that the only
workable solution for this mess is something on the order of my script that
routes around the damage, and beats systemd in submission. It's horribly
ugly, I'm embarassed that I actually had write such a clunker, but it seems
to actually makes network-online.target do what it's supposed to be doing in
the first place, but is apparently too complicated for either systemd, or
NetworkManager, to do correctly on their own.
So be it. Life's too short.