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.
Attachment:
pgpUIoT0X3_JR.pgp
Description: PGP signature
_______________________________________________ users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx
