Gordon Messmer writes:
On 12/20/2017 03:44 AM, Sam Varshavchik wrote:
> No managed switches here. Just some dumb switch with a bunch of stuff
> plugged into it.
Surprising, but the outcome is the same. You have a switch and a NIC which,
in concert, take a long time to negotiate a link, and that's a problem for
NetworkManager.
I'm not sure I see why this has to be a factor.
I just did a little experiment. I took a different server with an unused
port. I assigned an IP address to it, in its ifcfg file, then ifup-ed it.
The result:
3: eth1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel state
DOWN group default qlen 1000
link/ether 00:30:48:fc:83:fb brd ff:ff:ff:ff:ff:ff
inet 192.168.2.1/24 brd 192.168.2.255 scope global eth1
valid_lft forever preferred_lft forever
I then tested this using my script. I can bind it, without any issues.
strace:
bind(3, {sa_family=AF_INET, sin_port=htons(0),
sin_addr=inet_addr("192.168.2.1")}, 16) = 0
close(3)
Now, perhaps if networkmanager wants to wait a while, until there's a
carrier on that port, wonderful.
But why is there a problem with simply reading a configuration file that
says: "assign this static IP address to the port", and then assigning this
static IP address to the port? That's all anyone wants to do here. Nothing
more. Everything will then boot normally.
There's such a basic, fundamental disconnect here, somewhere, that I'm not
sure I can even describe it correctly. But to me, all of this seems to be a
no-brainer. There's an IP address in the ifcfg file. nm-online simply needs
to wait until this IP address is assigned to the network port. The End.