Cameron Simpson writes:
On 17Dec2017 18:05, sam varshavchik <mrsam(a)courier-mta.com>
wrote:
> But I really don't understand why so much research is needed for this issue,
> by disabling random things, and then trying other random things. Either
> NetworkManager-wait-online actually waits until the network interfaces have
> their IP address set, or it doesn't. If it's supposed to do it, then it
> should be possible to isolate the issue without turning it off completely
> and switching to a completely different network configuration
> infrastructure. If it's not supposed to do it, then what exactly is it
> supposed to be doing, anyway?
Someone pointed out that it seems to wait for the network services to start,
not for the IP assignments/allocation to complete.
As a scenario, consider dhclient. It typically tries to conduct an initial
DHCP negotiation, but after a little while backgrounds itself (and continues
to try).
What is your desired behaviour when DHCP service is not available?
During the process of trying to obtain or reauthorize a DHCP lease, you have
to reach a point where a conclusion is made: yes, I have successfully
acquired an IP address; or: no, I have not. Now if it's "I have not", you
may very well go into background and keep trying. But at this point a
statement can be made: this particular network interface is initialized, or
initialization has failed.
In the old days (you know, when systems managed to boot properly, how I miss
them), at that point the boot continues and let the chips fall where they
may.
It may certainly possible that the current dhclient cannot be made to work
this way. If so then, yes, this would be an issue. However that's completely
besides the point. Here we're not talking DHCP, we're talking about
STATICALLY ASSIGNED IP addresses. Fixed IP addresses. It is not rocket
science, and it is not unreasonable to expect that it should be easy to
establish when the network ports have been turned on and assigned those IP
addresses, so everything that uses those IP addresses can now be started.
Can someone tell me if what I'm asking for is really too much, and
impossible these days: don't start things at boot that depend on the network
interfaces with static IP addresses until those interfaces are actually up.
When we had initiscripts, I forget which one it was, but there was one that
read all the config files, and enabled those interfaces. And stuff that
depended on the network being up ran after that. Simple. Easy. So, again: is
it unreasonable to be able to start things that require the statically-
assigned IP addresses after they actually are assigned to their network
ports? Did something change, in the world we live in, where this is not
possible any more? And what exactly did change, that made this a logically
impossible, herculean task?
But when DHCP comes from one's ISP (be that a real ISP or some
LAN you don't
personally manage)?
Just outlining why NetworkManager-wait-online may not be doing what people
had hoped.
Maybe, but, again it's completely irrelevant. We're not talking about DHCP.
We're talking about fixed IP addresses. If NetworkManager – and if it is
indeed NetworkManager that's totally fraking up here – cannot do such a
simple, basic, elementary task as enabling ports with fixed IP addresses, at
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
actually reliably boot a server, in the brave new world of systemd and
NetworkManager, and there wouldn't be any reason to waste any more breath on
this nonsense.
Well, this is a fine way to start things on a Monday morning – this, and
also reading another dumpster fire in my mailbox, a different four year-old
bug which is pretty much the same thing – crap running when it's not
supposed to be running during boot – getting reopened.