Re: NetworkManager-wait-online is still utterly, and completely, broken

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, 2017-12-19 at 17:37 -0500, Sam Varshavchik wrote:
> 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.
> 

I think I have tracked down my problem with the help of
nm-wait-online-routes-gw.conf !

I have no explanation as to why this has started happening after
recent updates.

I had to turn the .conf into a script to get it to work - finger trouble I expect.
ja@hayling NetworkManager-wait-online.service.d 4$ cat script.conf
[Unit]
[Service]
ExecStart=/usr/bin/ja_nm-online.sh
[Install]

ja@hayling NetworkManager-wait-online.service.d 6$ cat /usr/bin/ja_nm-online.sh 
#!/bin/bash
# "LF=$'\n'; "' \

ROUTES=" \
  default \
  148.197.29.0/24 \
"; \
GW=148.197.29.5; \				Not a Gateway but my server


I beleive my NFS "failures" are caused by the VMware network interfaces "sometimes"
coming up before the "real" network interfaces.
(VMware Workstation 14 uses its own DHCP server not my DHCP server)
nm-online -s takes the vmware interfaces as a "working network".
nm-online (no -s) does not.

This "boot" would probably have caused an NFS mount failure
Just two interfaces up - before DHCP to my server has run.

Dec 20 13:35:50 hayling.jaa.org.uk NetworkManager[1035]: <info>  [1513776950.6441] manager: startup
complete
Dec 20 13:35:50 hayling.jaa.org.uk ja_nm-online.sh[1344]: 172.16.91.0/24 dev vmnet8 proto kernel scope
link src 172.16.91.1
Dec 20 13:35:50 hayling.jaa.org.uk ja_nm-online.sh[1344]: 192.168.111.0/24 dev vmnet1 proto kernel scope
link src 192.168.111.1
Dec 20 13:35:51 hayling.jaa.org.uk kernel: e1000e: enp0s31f6 NIC Link is Up 1000 Mbps Full Duplex, Flow
Control: Rx/Tx
Dec 20 13:35:51 hayling.jaa.org.uk kernel: IPv6: ADDRCONF(NETDEV_CHANGE): enp0s31f6: link becomes ready
...


Later all interfaces are up - after DHCP to my server has run

Dec 20 13:35:51 hayling.jaa.org.uk ja_nm-online.sh[1344]: default via 148.197.29.254 dev enp0s31f6 proto
static metric 100
Dec 20 13:35:51 hayling.jaa.org.uk ja_nm-online.sh[1344]: 148.197.29.0/24 dev enp0s31f6 proto kernel
scope link src 148.197.29.202 metric 100
Dec 20 13:35:51 hayling.jaa.org.uk ja_nm-online.sh[1344]: 172.16.91.0/24 dev vmnet8 proto kernel scope
link src 172.16.91.1
Dec 20 13:35:51 hayling.jaa.org.uk ja_nm-online.sh[1344]: 192.168.111.0/24 dev vmnet1 proto kernel scope
link src 192.168.111.1
Dec 20 13:35:51 hayling.jaa.org.uk ja_nm-online.sh[1344]: Network Manager Wait Online routes took 1
seconds
Dec 20 13:35:51 hayling.jaa.org.uk ja_nm-online.sh[1344]: Network Manager Wait Online gateway took 0
seconds
Dec 20 13:35:51 hayling.jaa.org.uk systemd[1]: Started Network Manager Wait Online.
Dec 20 13:35:51 hayling.jaa.org.uk audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295
subj=system_u:system_r:init_t:s0 msg='unit=NetworkManager-wait-online comm="systemd"
exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Dec 20 13:35:51 hayling.jaa.org.uk systemd[1]: Reached target Network is Online.
Dec 20 13:35:51 hayling.jaa.org.uk systemd[1]: Mounting /global...


_______________________________________________
users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx



[Index of Archives]     [Older Fedora Users]     [Fedora Announce]     [Fedora Package Announce]     [EPEL Announce]     [EPEL Devel]     [Fedora Magazine]     [Fedora Summer Coding]     [Fedora Laptop]     [Fedora Cloud]     [Fedora Advisory Board]     [Fedora Education]     [Fedora Security]     [Fedora Scitech]     [Fedora Robotics]     [Fedora Infrastructure]     [Fedora Websites]     [Anaconda Devel]     [Fedora Devel Java]     [Fedora Desktop]     [Fedora Fonts]     [Fedora Marketing]     [Fedora Management Tools]     [Fedora Mentors]     [Fedora Package Review]     [Fedora R Devel]     [Fedora PHP Devel]     [Kickstart]     [Fedora Music]     [Fedora Packaging]     [Fedora SELinux]     [Fedora Legal]     [Fedora Kernel]     [Fedora OCaml]     [Coolkey]     [Virtualization Tools]     [ET Management Tools]     [Yum Users]     [Yosemite News]     [Gnome Users]     [KDE Users]     [Fedora Art]     [Fedora Docs]     [Fedora Sparc]     [Libvirt Users]     [Fedora ARM]

  Powered by Linux