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

On 01/03/2018 04:53 PM, Rick Stevens wrote: As a network admin, I can see no reason to remove a fixed IP address from a NIC based on whether or not there's a carrier present. Even in the case of DHCP, unless the address lease expires between a disconnect and reconnect or there's pressure on the

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

Once upon a time, Rick Stevens said: > Now, if we want one of the uplinks to remain unavailable, it is marked > "administratively down" (in Cisco IOS-speak). For Linux, this would > essentially be "ip link dev down". This takes the link down, > but doesn't change the IP

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

On 01/01/2018 03:09 AM, Roberto Ragusa wrote: > On 12/24/2017 10:00 PM, Chris Adams wrote: >> Once upon a time, Sam Varshavchik said: >>> I defy anyone to identify a tangible benefit that comes from >>> removing a static IP address from a port when it loses carrier, and >>>

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

On 12/24/2017 10:00 PM, Chris Adams wrote: > Once upon a time, Sam Varshavchik said: >> I defy anyone to identify a tangible benefit that comes from >> removing a static IP address from a port when it loses carrier, and >> installing one only once a carrier is present. > >

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

Once upon a time, Sam Varshavchik said: > I defy anyone to identify a tangible benefit that comes from > removing a static IP address from a port when it loses carrier, and > installing one only once a carrier is present. It is useful for systems with multiple interfaces,

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

Roberto Ragusa writes: On 12/21/2017 06:28 PM, Gordon Messmer wrote: > Because NetworkManager is an event-driven system.  If an interface loses carrier for a defined period of time (5 seconds prior to the commit I've referenced), NM will remove the IP configuration from that interface.

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

On 12/21/2017 06:28 PM, Gordon Messmer wrote: > Because NetworkManager is an event-driven system.  If an interface loses > carrier for a defined period of time (5 seconds prior to the commit I've > referenced), NM will remove the IP configuration from that interface. And this is one of the

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

Marmorstein, Robert writes: NetworkManager-wait-online is to make sure that remote drives mount AFTER an IP address has been configured: https://www.freedesktop.org/wiki/Software/systemd/NetworkTarget/ That's exactly the use case that's broken here. By the way, my own experiments (on a lab

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

On 12/23/2017 11:54 AM, Marmorstein, Robert wrote: I agree that the nm-online manpage is confusing. My experiments seem to indicate that perhaps "active" means the network interface is "up" in the sense that the interface is listening for data-link layer (i.e. Ethernet) frames. It doesn't

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

> I would have thought something with "wait online" in its name would > actually wait for it to be on-line. To me, "on-line" means connected > and operational. Starting up but not actually on-line, isn't on-line. I find it interesting that freedesktop.org suggests that the entire purpose of

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

Tom Horsley writes: On Sat, 23 Dec 2017 10:50:44 -0500 Sam Varshavchik wrote: > Maybe, perhaps, this approach should've made sense to do so only when NM > actually was able to support all the functionality it was taking over? How's > that for a crazy idea? Does anyone think I'm being

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

On Sat, 23 Dec 2017 10:50:44 -0500 Sam Varshavchik wrote: > Maybe, perhaps, this approach should've made sense to do so only when NM > actually was able to support all the functionality it was taking over? How's > that for a crazy idea? Does anyone think I'm being completely off-base and >

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

Gordon Messmer writes: I understand what you're saying.  It's just that static configuration isn't what NM does.  The old network service does, and I sincerely hope no one ever suggests deprecating the network service unless NM offers that mode of operation, which it does not, today. I'm

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

On 12/21/2017 10:05 AM, Tom Horsley wrote: It's just that static configuration isn't what NM does. Which always struck me as very odd considering that redhat sponsors most of this stuff and mostly makes money off servers Mostly, yes.  They do have some desktop people, and sponsor GNOME

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

On Thu, 21 Dec 2017 09:28:27 -0800 Gordon Messmer wrote: > It's just that static configuration > isn't what NM does. Which always struck me as very odd considering that redhat sponsors most of this stuff and mostly makes money off servers which almost always have static configurations that

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

On 12/21/2017 04:17 AM, Sam Varshavchik wrote: I'm not sure I see why this has to be a factor. Because NetworkManager is an event-driven system.  If an interface loses carrier for a defined period of time (5 seconds prior to the commit I've referenced), NM will remove the IP configuration

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

francis.montag...@inria.fr writes: Hi. On Thu, 21 Dec 2017 07:17:38 -0500 Sam Varshavchik wrote: > 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: > I then tested

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

Hi. On Thu, 21 Dec 2017 07:17:38 -0500 Sam Varshavchik wrote: > 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: > I then tested this using my script. I can bind

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

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

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

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

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

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

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

On 20 Dec 2017 04:54, "Gordon Messmer" wrote: On 12/19/2017 04:46 PM, Sam Varshavchik wrote: > > That's the big picture. And looks like it's completely impossible to do > that, in stock Fedora. > Right now, yes. And that's completely and entirely down to

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

Gordon Messmer writes: On 12/19/2017 04:46 PM, Sam Varshavchik wrote: That's the big picture. And looks like it's completely impossible to do that, in stock Fedora. Right now, yes.  And that's completely and entirely down to NetworkManager bringing interfaces up in an event-driven

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

I've filed an RFE: https://bugzilla.redhat.com/show_bug.cgi?id=1527768 ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org

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

On 12/19/2017 04:46 PM, Sam Varshavchik wrote: That's the big picture. And looks like it's completely impossible to do that, in stock Fedora. Right now, yes.  And that's completely and entirely down to NetworkManager bringing interfaces up in an event-driven fashion, when link is

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

Gordon Messmer writes: Thanks, Sam, that looks like very useful information.  The logs you posted indicate that one interface, eno1, had no link when "ip addr show" ran, after NetworkManager reported itself online.  This seems consistent with nm- online's man page which indicates that

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

Thanks, Sam, that looks like very useful information.  The logs you posted indicate that one interface, eno1, had no link when "ip addr show" ran, after NetworkManager reported itself online.  This seems consistent with nm-online's man page which indicates that startup is complete when all

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

Louis Lagendijk writes: > Running diff on them shows pretty much the only differences you > would > expect: NAME, UUID, HWADDR, IPADDR*, PREFIX*, GATEWAY, and DNS* are > different. In terms of everything else, the config is the samen what happens if you change this to yes? Does nm-online then

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

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",

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

Joe Zeff writes: On 12/19/2017 11:27 AM, Sam Varshavchik wrote: "Wait for NetworkManager startup to complete, rather than waiting for network connectivity specifically. Startup is considered complete once NetworkManager has activated (or attempted to activate) every auto-activate

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

On Tue, 2017-12-19 at 14:14 -0500, Sam Varshavchik wrote: > Louis Lagendijk writes: > > > One question that has been bugging me for some time now: I wonder > > if > > nm-online checks for IP-addressing only when the "require ipv4 > > addressing for this connection to complete" option

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

Sam, Here's my understanding of the situation: * a network interface can either be active/started -- i.e., is in the "up" state, without necessarily having a network address -- or connected -- i.e., having an address; and * a system can have multiple network interfaces. I interpret "-s" to mean

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

On 12/19/2017 11:27 AM, Sam Varshavchik wrote: "Wait for NetworkManager startup to complete, rather than waiting for network connectivity specifically. Startup is considered complete once NetworkManager has activated (or attempted to activate) every auto-activate connection which is

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

Dr J Austin writes: I have read the nm-online man page about 10 times and I am still not clear what it is telling me. The way I parse it, without -s it waits until at least one network connection is present. With the option, it should wait until all connections are up. The man page starts

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

Louis Lagendijk writes: One question that has been bugging me for some time now: I wonder if nm-online checks for IP-addressing only when the "require ipv4 addressing for this connection to complete" option nm-connection- editor (which I guess results in IPV4_FAILURE_FATAL=yes being set in the

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

On Tue, 2017-12-19 at 07:16 -0500, Sam Varshavchik wrote: > Gordon Messmer writes: > > > On 12/18/2017 05:52 AM, Sam Varshavchik wrote: > > > Time IP addresses > > > == > > > 08:35:34 > > > 08:35:35 192.168.0.1 > > > > > > At 08:35:34 the server had no IP addresses > >

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

On Tue, 2017-12-19 at 07:16 -0500, Sam Varshavchik wrote: > Gordon Messmer writes: > > > On 12/18/2017 05:52 AM, Sam Varshavchik wrote: > > > Time IP addresses > > > == > > > 08:35:34 > > > 08:35:35 192.168.0.1 > > > > > > At 08:35:34 the server had no IP addresses > >

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

On 19 Dec 2017 07:49, wrote: On Mon, 18 Dec 2017 14:12:55 -0800 Gordon Messmer wrote: > On 12/17/2017 01:17 PM, francis.montag...@inria.fr wrote: >>Dec 17 21:32:59 X systemd[1]: Mounting /data2... >>Dec 17 21:33:19 X mount[996]: mount to NFS server 'Y'

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

On Tue, 19 Dec 2017 07:25:46 -0500 Tom Horsley wrote: > On Tue, 19 Dec 2017 20:16:51 +0800 >> FWIW, are you aware that you shouldn't make changes to >> /usr/lib/systemd/system/* files? These can be overwritten up >> updates. Yes yes, but we are debugging. >> If you want to make changes you

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

On Tue, 19 Dec 2017 20:16:51 +0800 Ed Greshko wrote: > FWIW, are you aware that you shouldn't make changes to  > /usr/lib/systemd/system/* > files?  These can be overwritten up updates.  If you want to make changes you > should > created a file with the same name in /etc/systemd/system.  And

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

On 12/19/17 19:17, Dr J Austin wrote: > On Mon, 2017-12-18 at 19:24 -0500, Sam Varshavchik wrote: >> Gordon Messmer writes: >> >>> On 12/18/2017 05:52 AM, Sam Varshavchik wrote: Time IP addresses == 08:35:34 08:35:35 192.168.0.1 At 08:35:34

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

Gordon Messmer writes: On 12/18/2017 05:52 AM, Sam Varshavchik wrote: Time IP addresses == 08:35:34 08:35:35 192.168.0.1 At 08:35:34 the server had no IP addresses Well, it probably had 127.0.0.1, which brings into question what the complete state of the network

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

On Mon, 2017-12-18 at 19:24 -0500, Sam Varshavchik wrote: > Gordon Messmer writes: > > > On 12/18/2017 05:52 AM, Sam Varshavchik wrote: > > > Time IP addresses > > > == > > > 08:35:34 > > > 08:35:35 192.168.0.1 > > > > > > At 08:35:34 the server had no IP addresses > >

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

On Mon, 18 Dec 2017 14:12:55 -0800 Gordon Messmer wrote: > On 12/17/2017 01:17 PM, francis.montag...@inria.fr wrote: >>Dec 17 21:32:59 X systemd[1]: Mounting /data2... >>Dec 17 21:33:19 X mount[996]: mount to NFS server 'Y' failed: Resource >> temporarily unavailable, retrying >>Dec

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

Gordon Messmer writes: On 12/18/2017 05:52 AM, Sam Varshavchik wrote: Time IP addresses == 08:35:34 08:35:35 192.168.0.1 At 08:35:34 the server had no IP addresses Well, it probably had 127.0.0.1, which brings into question what the complete state of the network

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

On 12/18/2017 05:52 AM, Sam Varshavchik wrote: Time IP addresses == 08:35:34 08:35:35 192.168.0.1 At 08:35:34 the server had no IP addresses Well, it probably had 127.0.0.1, which brings into question what the complete state of the network was. Could you arrange

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

On 12/17/2017 01:17 PM, francis.montag...@inria.fr wrote: On Sun, 17 Dec 2017 11:49:39 -0800 Gordon Messmer wrote: In order to determine that, someone who can reproduce the problem needs to revert that specific change on their system. With that declaration in /etc/fstab: Y:/data2

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

On Mon, 18 Dec 2017 09:56:03 -0700 stan wrote: > Boot went to multi-threaded, and so > became non-deterministic, in order to shorten boot time. And that has saved oh so much time compared to the time every sysadmin has spent fighting with it :-). ___

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

On Mon, 2017-12-18 at 09:56 -0700, stan wrote: > On Mon, 18 Dec 2017 07:19:02 -0500 > Sam Varshavchik wrote: > > > 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

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

On Mon, 18 Dec 2017 07:19:02 -0500 Sam Varshavchik wrote: > 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. >

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

Sam Varshavchik writes: 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

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

Allegedly, on or about 18 December 2017, Cameron Simpson sent: > NetworkManager-wait-online may not be doing what people had hoped. I would have thought something with "wait online" in its name would actually wait for it to be on-line. To me, "on-line" means connected and operational. Starting

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

Cameron Simpson writes: On 17Dec2017 18:05, sam varshavchik 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

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

On Sun, Dec 17, 2017 at 2:49 PM, Gordon Messmer wrote: > On 12/17/2017 08:38 AM, Tom H wrote: >> >> Yes, it's the same thing as doing what I suggested next and you >> snipped out. > > Not exactly... I'd like to know if this commit is the one that broke > the service: > >

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

On Sun, Dec 17, 2017 at 11:44 AM, Chris Murphy wrote: > On Sun, Dec 17, 2017 at 8:41 AM, Dr J Austin wrote: >> I gave up using ldap/autofs some time ago and until the last update >> the _netdev option in fstab (or something else maybe) has been working

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

On 17Dec2017 18:05, sam varshavchik 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

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

Tom H writes: Does privoxy start properly if you disable NM and its wait-online unit and use systemd-networkd and its wait-online unit? Does privoxy start properly if you disable NM's wait-online unit and use a custom wait-online unit that waits until "/sys/class/net//carrier" is "1"?

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

On Sun, 17 Dec 2017 11:49:39 -0800 Gordon Messmer wrote: > Not exactly... I'd like to know if this commit is the one that broke the > service: >

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

On 12/17/2017 08:38 AM, Tom H wrote: Yes, it's the same thing as doing what I suggested next and you snipped out. Not exactly... I'd like to know if this commit is the one that broke the service:

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

On Sun, Dec 17, 2017 at 8:41 AM, Dr J Austin wrote: > On Sun, 2017-12-17 at 08:20 -0500, Tom Horsley wrote: >> On Sun, 17 Dec 2017 11:07:52 + >> Dr J Austin wrote: >> >> > Anyone else with the same problem/ >> >> I gave up on getting NFS mounts to work a long time ago. >> I

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

On Sun, Dec 17, 2017 at 11:23 AM, Gordon Messmer wrote: > On 12/17/2017 07:18 AM, Tom H wrote: >> >> I've just read "man nm-online" (possibly for the first time!) and >> "nm-online -s" doesn't seem to do what >> "NetworkManager-wait-online.service" is supposed to do,

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

On 12/17/2017 07:18 AM, Tom H wrote: I've just read "man nm-online" (possibly for the first time!) and "nm-online -s" doesn't seem to do what "NetworkManager-wait-online.service" is supposed to do, systemd-wise. It waits "for NetworkManager startup to complete, rather than waiting for network

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

On Sun, 2017-12-17 at 08:20 -0500, Tom Horsley wrote: > On Sun, 17 Dec 2017 11:07:52 + > Dr J Austin wrote: > > > Anyone else with the same problem/ > > I gave up on getting NFS mounts to work a long time ago. > I have a job I start with "at now" in rc.local that > delays for a few seconds

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

On Sat, Dec 16, 2017 at 10:03 AM, Sam Varshavchik wrote: > > Just had another boot that utterly failed because services that were > supposed to start only after the network interfaces came up, didn't. They > started too soon. Privoxy's logfile has the smoking gun: > >

Announcing the "Unfrak Systemd" project (was Re: NetworkManager-wait-online is still utterly, and completely, broken)

Dr J Austin writes: On Sat, 2017-12-16 at 10:03 -0500, Sam Varshavchik wrote: > Why is it so friggin difficult to get something this simple, this basic > concept of starting things only after the network interfaces are up, working > correctly, and reliably? > > Oh yeah, I know. systemd.

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

broken In-reply-to: Your message of "Sun, 17 Dec 2017 08:20:37 -0500." <20171217082037.2148ddd8@zooty> On Sun, 17 Dec 2017 08:20:37 -0500 Tom Horsley wrote: > On Sun, 17 Dec 2017 11:07:52 + > Dr J Austin wrote: >> Anyone else with the same problem/ > I gave up on getting NFS

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

On Sun, 17 Dec 2017 11:07:52 + Dr J Austin wrote: > Anyone else with the same problem/ I gave up on getting NFS mounts to work a long time ago. I have a job I start with "at now" in rc.local that delays for a few seconds then does all the NFS mounts. I have other commands in there as well to

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

On Sat, 2017-12-16 at 10:03 -0500, Sam Varshavchik wrote: > Just had another boot that utterly failed because services that were > supposed to start only after the network interfaces came up, didn't. They > started too soon. Privoxy's logfile has the smoking gun: > > 2017-12-16 09:42:39.875

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

Just had another boot that utterly failed because services that were supposed to start only after the network interfaces came up, didn't. They started too soon. Privoxy's logfile has the smoking gun: 2017-12-16 09:42:39.875 7f4acdaa6740 Fatal error: can't bind to 192.168.0.1:8000: Cannot