Cameron Simpson writes:
On 17Dec2017 18:05, sam varshavchik <mrsam@xxxxxxxxxxxxxxx> 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.
Attachment:
pgpi1qsFtzBkM.pgp
Description: PGP signature
_______________________________________________ users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx
