privoxy.service most certainly has:
Wants=network-online.target After=network-online.target
I'm staring at this service file, right now.
I have privoxy binding to an internal IP address, of course:
listen-address 192.168.0.1:8000
However, privoxy just failed to start for me, after a reboot.
2017-11-04 09:16:52.710 7f8d7a298700 Fatal error: can't bind to 192.168.0.1:8000: Cannot assign requested address
Would anyone care to guess what the problem is (no need to mention the obvious, one-word answer, although I'd fully agree with it), given that:
Nov 4 09:16:52 shorty systemd[1]: Started Network Manager Wait Online.
This was, in syslog, **BEFORE** the lines that were logging failures to start due to the IP addresses not being assigned.
I also determined that this is not a privoxy-specific issue, since I found another message in syslog, after this one, that reported a failure to bind to the IP address in question.
192.168.0.1 is a static IP address. DHCP is not in the picture here. I created bug 1509544 for this, but I am not holding any illusions, here.
On Sat, Nov 4, 2017 at 9:51 AM, Tom Horsley horsley1953@gmail.com wrote:
Systemd has no idea what "up" means for networking
More accurately, the network-online.target doesn't mean what a reasonable person would think it means. It actually means that the base network drivers have been loaded, not that all the network interfaces are properly configured. For most of us, this is useless.
If you are using NetworkManager (default for Fedora), then you can use the NetworkManager-wait-online service instead, e.g.
After=NetworkManager-wait-online.service
This has always worked for me.
Less kludgy than using a sleep, but obviously it only works if you are running NetworkManager and this service is enabled.
--Greg
On Sat, Nov 4, 2017 at 11:14 AM, Greg Woods woods@ucar.edu wrote:
On Sat, Nov 4, 2017 at 9:51 AM, Tom Horsley horsley1953@gmail.com wrote:
Systemd has no idea what "up" means for networking
More accurately, the network-online.target doesn't mean what a reasonable person would think it means. It actually means that the base network drivers have been loaded, not that all the network interfaces are properly configured. For most of us, this is useless.
You've described "network.target" not "network-online.target".
On Sat, Nov 4, 2017 at 9:57 AM, Sam Varshavchik mrsam@courier-mta.com wrote:
privoxy.service most certainly has:
Wants=network-online.target After=network-online.target
I'm staring at this service file, right now.
I have privoxy binding to an internal IP address, of course:
listen-address 192.168.0.1:8000
However, privoxy just failed to start for me, after a reboot.
2017-11-04 09:16:52.710 7f8d7a298700 Fatal error: can't bind to 192.168.0.1:8000: Cannot assign requested address
Would anyone care to guess what the problem is (no need to mention the obvious, one-word answer, although I'd fully agree with it), given that:
Nov 4 09:16:52 shorty systemd[1]: Started Network Manager Wait Online.
This was, in syslog, **BEFORE** the lines that were logging failures to start due to the IP addresses not being assigned.
I also determined that this is not a privoxy-specific issue, since I found another message in syslog, after this one, that reported a failure to bind to the IP address in question.
192.168.0.1 is a static IP address. DHCP is not in the picture here. I created bug 1509544 for this, but I am not holding any illusions, here.
Is "NetworkManager-wait-online.service" or "systemd-networkd-wait-online.service" enabled?
If you're using "/etc/rc.d/init.d/network", have you created and enabled a similar service?
Tom H writes:
192.168.0.1 is a static IP address. DHCP is not in the picture here. I created bug 1509544 for this, but I am not holding any illusions, here.
Is "NetworkManager-wait-online.service" or "systemd-networkd-wait-online.service" enabled?
If you're using "/etc/rc.d/init.d/network", have you created and enabled a similar service?
Looks like systemd-networkd-wait-online.service is disabled by default in Fedora.
Given that there are packages that require all IP addresses to be configured, and thus declare a dependency on network-online.target, it does not seem logical for NetworkManager, if installed, to not enable this if this was, indeed, the issue.
If the packaging guidelines are for a package dependency on network- online.target, and especially if NetworkManager is installed by default – as it is, then it seems wrong not to have this enabled by default.
On 11/04/2017 09:48 PM, Sam Varshavchik wrote:
Looks like systemd-networkd-wait-online.service is disabled by default in Fedora.
Given that there are packages that require all IP addresses to be configured, and thus declare a dependency on network-online.target, it does not seem logical for NetworkManager, if installed, to not enable this if this was, indeed, the issue.
If the packaging guidelines are for a package dependency on network-online.target, and especially if NetworkManager is installed by default – as it is, then it seems wrong not to have this enabled by default.
What would that even mean? That service has no meaning by itself. Of course, NetworkManager will start the network interfaces even without it. The whole purpose of that service is to delay any other services that require the network to be started before running.
See the output of: systemctl --before list-dependencies systemd-networkd-wait-online.service
However, the one you really should use for ensuring a service has network available is network-online.target. That one covers more than just NetworkManager.
Samuel Sieb writes:
What would that even mean? That service has no meaning by itself. Of course, NetworkManager will start the network interfaces even without it. The whole purpose of that service is to delay any other services that require the network to be started before running.
See the output of: systemctl --before list-dependencies systemd-networkd-wait-online.service
However, the one you really should use for ensuring a service has network available is network-online.target. That one covers more than just NetworkManager.
Except that's precisely what privoxy's service file does, yet I still ended up with a broken boot because not just privoxy but also at least one other service got started before all IP addresses were set up. Which was the initial message that started this thread.
Then someone else claimed that the real target that should be used for this is this NetworkManager's target.
That, you're claiming it's network-online.target. Others are claiming that systemd-networkd-wait-online.service is the correct target, to ensure that all IP addresses are configured.
It really doesn't matter which target it really is. I simply want a reliable boot. I don't think that's too much to ask. Unfortunately, with systemd, nobody really knows how it works, apparently. I don't particularly care about flaming systemd, but with utter crap like this I see very few other options. It doesn't really matter what's the right answer here. Just because nobody really knows how it's supposed to work, or which targets should be enabled by default, is precisely why it's flaming garbage. And this state of affairs is rather sad.
On Sun, Nov 5, 2017 at 8:36 AM, Sam Varshavchik mrsam@courier-mta.com wrote:
Samuel Sieb writes:
What would that even mean? That service has no meaning by itself. Of course, NetworkManager will start the network interfaces even without it. The whole purpose of that service is to delay any other services that require the network to be started before running.
See the output of: systemctl --before list-dependencies systemd-networkd-wait-online.service
However, the one you really should use for ensuring a service has network available is network-online.target. That one covers more than just NetworkManager.
Except that's precisely what privoxy's service file does, yet I still ended up with a broken boot because not just privoxy but also at least one other service got started before all IP addresses were set up. Which was the initial message that started this thread.
Then someone else claimed that the real target that should be used for this is this NetworkManager's target.
That, you're claiming it's network-online.target. Others are claiming that systemd-networkd-wait-online.service is the correct target, to ensure that all IP addresses are configured.
It's both. systemd has "network.target", which is equivalent to the LSB's "$network" facility but neither guarantee that the network is up, only that the network management software has run or is running, and "network-online.target", which guarantees that the network is up. In order to use "network-online.target", you have to enable one of the "wait-online" units.
On 11/05/2017 05:36 AM, Sam Varshavchik wrote:
Unfortunately, with systemd, nobody really knows how it works, apparently.
There do appear to be a few people here who don't understand how it works, but that's hardly systemd's fault. This specific subject is documented thoroughly:
https://www.freedesktop.org/wiki/Software/systemd/NetworkTarget/
The short answer is, on a default current Fedora system, you simply need to run:
systemctl enable NetworkManager-wait-online.service
Gordon Messmer writes:
On 11/05/2017 05:36 AM, Sam Varshavchik wrote:
Unfortunately, with systemd, nobody really knows how it works, apparently.
There do appear to be a few people here who don't understand how it works, but that's hardly systemd's fault. This specific subject is documented thoroughly:
https://www.freedesktop.org/wiki/Software/systemd/NetworkTarget/
The short answer is, on a default current Fedora system, you simply need to run:
systemctl enable NetworkManager-wait-online.service
Now, as I see it, this boils down to a one word, simple question:
Why?
Do we really expect that one should actually do that?
Using privoxy as an illustrative example: is it really so unreasonable to expect that installing a package called "privoxy", and if this "privoxy" package requires all IP addresses to be up, before it runs, then installing this package makes sure that this actually happens, that it starts up after all network interfaces are up? Is that really too much to expect for this to happen, without having to run Google searches? Why does anyone need find some web site, in order to figure out what arcane command one needs to run, in order to make the package work? Isn't that what installing the package, in the first place, is supposed to accomplish?
After all, isn't it what having a package is all about, in the first place? If, after installing a package, one needs to find some web site which tells you what commands need to be executed in order to actually make it work properly, then I see no point to having installable packages in the first place. One might as well compile from source, and install it manually, and then accept the responsibility to figure out everything else that needs to be done in order to have the package start and run correctly, on the system.
I always though that the whole purpose of having an installable package is that once you install it, it's correctly configured, and is ready to run. Perhaps, at the most, after one additional, enabling/activation step. Perhaps I was wrong. Maybe I shouldn't expect that some feature release of, say, Libreoffice will always run after I install it. Maybe I should be prepared that it will install but not run at all, and instead dump a cryptic message to syslog, until I hit the correct Google search, and figure out what command I need to run, manually, before Libreoffice will start up.
On Sun, Nov 5, 2017 at 8:10 PM, Sam Varshavchik mrsam@courier-mta.com wrote:
Gordon Messmer writes:
On 11/05/2017 05:36 AM, Sam Varshavchik wrote:
Unfortunately, with systemd, nobody really knows how it works, apparently.
There do appear to be a few people here who don't understand how it works, but that's hardly systemd's fault. This specific subject is documented thoroughly:
https://www.freedesktop.org/wiki/Software/systemd/NetworkTarget/
The short answer is, on a default current Fedora system, you simply need to run:
systemctl enable NetworkManager-wait-online.service
Now, as I see it, this boils down to a one word, simple question:
Why?
Because that's the way that systemd's been designed.
It's unfortunately convoluted :(
Do we really expect that one should actually do that?
Using privoxy as an illustrative example: is it really so unreasonable to expect that installing a package called "privoxy", and if this "privoxy" package requires all IP addresses to be up, before it runs, then installing this package makes sure that this actually happens, that it starts up after all network interfaces are up?
It wouldn't be unreasonable. It'd be better if services depending on the network being up could express that dependency and have it be respected without having to enable another service (that itself depends on the network management software in use).
To paraphrase Donald Trump "networking is difficult." Early versions of systemd had a crappy interaction with networking but it's been improving version after version; however, upstream might not consider the current wait-online situation broken or lacking...
systemd isn't the first sysvinit replacement to encounter problems. I remember an Ubuntu bug where nfs (mounting?) was failing on a multi-nic system because the condition for starting the job was that any interface other than lo should be up (IIRC, the upstart syntax was something like "net-device-up iface!=lo") and the non-nfs interface was often/always up before the nfs one. In practice and implementation, "networking is difficult."
Tom H writes:
On Sun, Nov 5, 2017 at 8:10 PM, Sam Varshavchik mrsam@courier-mta.com wrote:
Gordon Messmer writes:
On 11/05/2017 05:36 AM, Sam Varshavchik wrote:
Unfortunately, with systemd, nobody really knows how it works, apparently.
There do appear to be a few people here who don't understand how it works, but that's hardly systemd's fault. This specific subject is documented thoroughly:
https://www.freedesktop.org/wiki/Software/systemd/NetworkTarget/
The short answer is, on a default current Fedora system, you simply need to run:
systemctl enable NetworkManager-wait-online.service
Now, as I see it, this boils down to a one word, simple question:
Why?
Because that's the way that systemd's been designed.
It's unfortunately convoluted :(
Again, my rhetorical question didn't land properly. I'm not very good with rhetorical questions.
systemd isn't the first sysvinit replacement to encounter problems. I
Well, maybe there's a lesson to learn from that.
Allegedly, on or about 5 November 2017, Sam Varshavchik sent:
Now, as I see it, this boils down to a one word, simple question:
Why?
Do we really expect that one should actually do that?
Using privoxy as an illustrative example: is it really so unreasonable to expect that installing a package called "privoxy", and if this "privoxy" package requires all IP addresses to be up, before it runs, then installing this package makes sure that this actually happens, that it starts up after all network interfaces are up?
I tend to agree. But rather than thinking that a packet that requires a running network ought to start another waiting service to get it to wait for the right moment. Ought to depend on *that* waiting service, rather than listen to the wrong service.
There's any number of services on Fedora that should be waiting for a network is operational status, rather than a network is starting status. They should depend on a service that actually provides that information, not rely on something else to delay the wrong thing that they're listening to.
Tim writes:
Allegedly, on or about 5 November 2017, Sam Varshavchik sent:
Now, as I see it, this boils down to a one word, simple question:
Why?
Do we really expect that one should actually do that?
Using privoxy as an illustrative example: is it really so unreasonable to expect that installing a package called "privoxy", and if this "privoxy" package requires all IP addresses to be up, before it runs, then installing this package makes sure that this actually happens, that it starts up after all network interfaces are up?
I tend to agree. But rather than thinking that a packet that requires a running network ought to start another waiting service to get it to wait for the right moment. Ought to depend on *that* waiting service, rather than listen to the wrong service.
You are proposing to modify each upstream package to inject custom code that will wait for all IP addresses to be configured, before proceeding?
And you think this is easier, and more maintanable, then simply fixing the broken systemd configuration just once, and not have to figure out whether or not each individual package requires this dependency, and be responsible for patching it, in perpetuity?
Allegedly, on or about 7 November 2017, Sam Varshavchik sent:
You are proposing to modify each upstream package to inject custom code that will wait for all IP addresses to be configured, before proceeding?
And you think this is easier, and more maintanable, then simply fixing the broken systemd configuration just once, and not have to figure out whether or not each individual package requires this dependency, and be responsible for patching it, in perpetuity?
I'll take that in two chunks:
1. Are external packages imported verbatim? Does Fedora not customise packages for itself? Do other distros customise packages?
2. And I'll use NTP as an example, and I'll talk about an old version because I've not tried this out recently:
Back when I was on dial-up, I'd have to restart NTP after dialling my ISP, because it never noticed a WAN connection coming alive. When NTP started (before I was online), it tried to use internet servers to sync itself, of course it failed, and *never* attempted it again. It didn't watch out for a WAN interface activating, it didn't periodically retry the internet servers it was going to use before, it just aborted and failed.
To my mind, that was lousy programming, and broken by design. Its behaviour *needed* changing. Modifying the distro's version would have been a good starting point. Having that modification upstreamed would have been even better.
Having the failing program actually look for the right thing (is the interface it needs to use available, can it simply keep retrying the servers it was going to use, etc.), was going to be the far better solution, than leaving it in it's (then) currently badly programmed condition, and bodging up some other network-alive status flag to mean something different than it says it means.
It should be simple (as you seemed to be arguing beforehand). There should be some flag that says there's an active network path to the real world, and networking software that needs that information should look for *that* flag.
I remember a similar argument to this, a long time ago. Various services were looking at the wrong flag (a network has started), rather than the appropriate one (a network is working). And it was stated that such packages ought to be modified to look in the right place.
That's exactly the kind of thing I would advocate. Rather than wedge another detection routine in front of the wrong status flag that everything is looking at, and allowing them to keep looking at the wrong status flag.
Unfortunately, with systemd, nobody really knows how it works, apparently.
There do appear to be a few people here who don't understand how it works, but that's hardly systemd's fault. This specific subject is documented thoroughly:
https://www.freedesktop.org/wiki/Software/systemd/NetworkTarget/
Here's what I got from that page.
1. Here's a list of definitions of "networking is up", ranging from sensible to esoteric to incredibly rare. 2. The world is complex. 3. None of this is actually our problem. 4. We didn't bother to do much research into what "reasonable" should be. 5. Try this one thing which doesn't actually work how it's described. 6. When in doubt, it's not systemd's fault.
The short answer is, on a default current Fedora system, you simply need to run:
systemctl enable NetworkManager-wait-online.service
Yet as many people here have pointed out, this doesn't actually behave in the way people here would like for it to behave, or even how it's described in that page.
In other words, "[we]'re holding it wrong."
-justin
users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org
On Sun, Nov 5, 2017 at 12:48 AM, Sam Varshavchik mrsam@courier-mta.com wrote:
Tom H writes:
192.168.0.1 is a static IP address. DHCP is not in the picture here. I created bug 1509544 for this, but I am not holding any illusions, here.
Is "NetworkManager-wait-online.service" or "systemd-networkd-wait-online.service" enabled?
If you're using "/etc/rc.d/init.d/network", have you created and enabled a similar service?
Looks like systemd-networkd-wait-online.service is disabled by default in Fedora.
Given that there are packages that require all IP addresses to be configured, and thus declare a dependency on network-online.target, it does not seem logical for NetworkManager, if installed, to not enable this if this was, indeed, the issue.
If the packaging guidelines are for a package dependency on network-online.target, and especially if NetworkManager is installed by default – as it is, then it seems wrong not to have this enabled by default.
Would boot be slowed down (by 30s?) if you switch to systemd-networkd for network management and "NetworkManager-wait-online.service" is enabled?
Tom H writes:
On Sun, Nov 5, 2017 at 12:48 AM, Sam Varshavchik mrsam@courier-mta.com wrote:
If the packaging guidelines are for a package dependency on network-online.target, and especially if NetworkManager is installed by default – as it is, then it seems wrong not to have this enabled by default.
Would boot be slowed down (by 30s?) if you switch to systemd-networkd for network management and "NetworkManager-wait-online.service" is enabled?
I just about finished writing a fairly extensive reply to this, when I decided to delete it all, and replace it with just a simple, basic question.
Why is it so difficult to make sure that a service gets started after all IP addresses are set up by the system, for services that have this requirement?
Why is it even necessary to argue which is the correct target for that, or which system tool should be used to manage the system?
This doesn't seem like rocket science to me.
This seems like a fairly, basic, fundamental, aspect of system administration. Can we agree on that? It should not be up to an individual service to figure out how to do that. There should be a fairly clear bit set somewhere, in however a particular's service configuration that says: "start me at boot after all IP addresses are configured", and whatever the system administration tool is responsible for that, it makes it so. And it does so in a fairly clear, and unambiguous manner. It shouldn't be necessary for anyone to take any additional, manual steps. That's how things should be set up out of the box.
I really would like to make sure that everyone agrees with this novel idea.
Nobody should be saying, well, maybe try this, that or the other. That's just missing the point, completely.
On Sun, 05 Nov 2017 08:52:33 -0500 Sam Varshavchik wrote:
Why is it so difficult to make sure that a service gets started after all IP addresses are set up by the system, for services that have this requirement?
Because systemd is brought to you by the same people that brought you NetworkManager, and NetworkManager believes it is a bug if any service needs networking at startup. All services are supposed to listen for network changes and automagically reconfigure themselves on the new network (which also might be the very first network).
Why redhat sponsors this stuff I have no idea since they sell primarily to the server market and this is exactly the opposite of what you want in a server.
Tom Horsley writes:
On Sun, 05 Nov 2017 08:52:33 -0500 Sam Varshavchik wrote:
Why is it so difficult to make sure that a service gets started after all
IP
addresses are set up by the system, for services that have this
requirement?
Because systemd is brought to you by the same people that brought you NetworkManager, and NetworkManager believes it is a bug if any service needs networking at startup. All services are supposed to listen for network changes and automagically reconfigure themselves on the new network (which also might be the very first network).
Why redhat sponsors this stuff I have no idea since they sell primarily to the server market and this is exactly the opposite of what you want in a server.
It should've been obvious that I was asking a rhetorical question.
On 11/05/2017 06:18 AM, Tom Horsley wrote:
Because systemd is brought to you by the same people that brought you NetworkManager
Yes, if you define "the same people" as "Red Hat." But in that case, a great deal of the GNU/Linux stack, including gcc, glibc, and Linux (the kernel) are brought to you by the same people that brought you systemd, and that statement carries very little meaning.
Hi.
On Sun, 05 Nov 2017 08:52:33 -0500 Sam Varshavchik wrote:
Why is it so difficult to make sure that a service gets started after all IP addresses are set up by the system, for services that have this requirement?
Using a dependency (Wants and After) to network-online.target is the proper way to do that. Your privoxy.service is thus correct.
You must then verify that network-online.target is properly configured,
There is (mostly) two ways to start the network:
- with NetworManager - with systemd-networkd
Both of them start asynchronously (are seen started by systemd *before* the network interfaces are configured).
To achieve synchronisation you must enable:
- NetworkManager-wait-online.service if you use NetworManager - or systemd-networkd-wait-online.service if you use systemd-networkd
Those wait-online service are WantedBy network-online.target
Can you verify those 4 services on your machine?
For example with:
systemctl -n 0 status NetworkManager{,-wait-online} systemd-networkd{,-wait-online}
-- Francis
On Sun, Nov 5, 2017 at 8:52 AM, Sam Varshavchik mrsam@courier-mta.com wrote:
Tom H writes:
On Sun, Nov 5, 2017 at 12:48 AM, Sam Varshavchik mrsam@courier-mta.com wrote:
If the packaging guidelines are for a package dependency on network-online.target, and especially if NetworkManager is installed by default – as it is, then it seems wrong not to have this enabled by default.
Would boot be slowed down (by 30s?) if you switch to systemd-networkd for network management and "NetworkManager-wait-online.service" is enabled?
I just about finished writing a fairly extensive reply to this, when I decided to delete it all, and replace it with just a simple, basic question.
Why is it so difficult to make sure that a service gets started after all IP addresses are set up by the system, for services that have this requirement?
Why is it even necessary to argue which is the correct target for that, or which system tool should be used to manage the system?
This doesn't seem like rocket science to me.
This seems like a fairly, basic, fundamental, aspect of system administration. Can we agree on that? It should not be up to an individual service to figure out how to do that. There should be a fairly clear bit set somewhere, in however a particular's service configuration that says: "start me at boot after all IP addresses are configured", and whatever the system administration tool is responsible for that, it makes it so. And it does so in a fairly clear, and unambiguous manner. It shouldn't be necessary for anyone to take any additional, manual steps. That's how things should be set up out of the box.
I really would like to make sure that everyone agrees with this novel idea.
Nobody should be saying, well, maybe try this, that or the other. That's just missing the point, completely.
As I said in my previous email, if you want to ensure that the network's up for services that depend on "network-online.target", you have to enable the right "wait-online" service.
It's too bad that systemd doesn't provide a generic "systemd-wait-online.service" that can ensure that the network's up without using a specific software stack's implementation and methods.
The challenge here is that systemd considers "the network" to be up if *any* networking devices are up. I ran into this on my MythTV setup, where once the InfiniTV capture card was up (which uses a virtual network interface), systemd would give the green light for every other service to start up. Of course the virtual network interface would always come up first since it was just a kernel module loading, and didn't require a back-and-forth DHCP request. So bunches of services which bind to all available interfaces at start-up would bind to loopback and the capture card and that's it.
Per systemd this is "working as intended" because how are they supposed to know which network interface you want?
I solved this by putting a "sleep 5" into the start of network-online.target.
-justin
On Sun, Nov 5, 2017 at 11:05 AM, Tom H tomh0665@gmail.com wrote:
On Sun, Nov 5, 2017 at 8:52 AM, Sam Varshavchik mrsam@courier-mta.com wrote:
Tom H writes:
On Sun, Nov 5, 2017 at 12:48 AM, Sam Varshavchik <mrsam@courier-mta.com
wrote:
If the packaging guidelines are for a package dependency on network-online.target, and especially if NetworkManager is installed by default – as it is, then it seems wrong not to have this enabled by default.
Would boot be slowed down (by 30s?) if you switch to systemd-networkd for network management and "NetworkManager-wait-online.service" is enabled?
I just about finished writing a fairly extensive reply to this, when I decided to delete it all, and replace it with just a simple, basic question.
Why is it so difficult to make sure that a service gets started after all IP addresses are set up by the system, for services that have this requirement?
Why is it even necessary to argue which is the correct target for that, or which system tool should be used to manage the system?
This doesn't seem like rocket science to me.
This seems like a fairly, basic, fundamental, aspect of system administration. Can we agree on that? It should not be up to an individual service to figure out how to do that. There should be a fairly clear bit set somewhere, in however a particular's service configuration that says: "start me at boot after all IP addresses are configured", and whatever the system administration tool is responsible for that, it makes it so. And it does so in a fairly clear, and unambiguous manner. It shouldn't be necessary for anyone to take any additional, manual steps. That's how things should be set up out of the box.
I really would like to make sure that everyone agrees with this novel idea.
Nobody should be saying, well, maybe try this, that or the other. That's just missing the point, completely.
As I said in my previous email, if you want to ensure that the network's up for services that depend on "network-online.target", you have to enable the right "wait-online" service.
It's too bad that systemd doesn't provide a generic "systemd-wait-online.service" that can ensure that the network's up without using a specific software stack's implementation and methods. _______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org
On Sun, Nov 5, 2017 at 11:22 AM, Justin Moore justin.nonwork@gmail.com wrote:
The challenge here is that systemd considers "the network" to be up if *any* networking devices are up. I ran into this on my MythTV setup, where once the InfiniTV capture card was up (which uses a virtual network interface), systemd would give the green light for every other service to start up. Of course the virtual network interface would always come up first since it was just a kernel module loading, and didn't require a back-and-forth DHCP request. So bunches of services which bind to all available interfaces at start-up would bind to loopback and the capture card and that's it.
Per systemd this is "working as intended" because how are they supposed to know which network interface you want?
I solved this by putting a "sleep 5" into the start of network-online.target.
Please bottom-post.
In the networkd case, you can specify an interface
# /lib/systemd/systemd-networkd-wait-online -h systemd-networkd-wait-online [OPTIONS...]
Block until network is configured.
-h --help Show this help --version Print version string -q --quiet Do not show status information -i --interface=INTERFACE Block until at least these interfaces have appeared --ignore=INTERFACE Don't take these interfaces into account --timeout=SECS Maximum time to wait for network connectivity
so you can override the distribution-supplied "systemd-networkd-wait-online.service".
On Sun, 05 Nov 2017 12:24:15 -0500 Tom H wrote:
On Sun, Nov 5, 2017 at 11:22 AM, Justin Moore justin.nonwork@gmail.com wrote:
The challenge here is that systemd considers "the network" to be up if *any* networking devices are up.
Probably only in the NetworkManager case:
When run, nm-online waits until NetworkManager reports an active connection, or specified timeout expires.
In the networkd case, you can specify an interface
Right but that is probably useless since:
systemd-networkd-wait-online is a one-shot system service that waits for the network to be configured. By default, it will wait for all links it is aware of and which are managed by systemd-networkd.service(8) to be fully configured or failed, and for at least one link to gain a carrier.
One argument to switch to systemd-networkd ... I will personally not :-(
On Sun, Nov 5, 2017 at 12:41 PM, Francis.Montagnac@inria.fr wrote:
On Sun, 05 Nov 2017 12:24:15 -0500 Tom H wrote:
In the networkd case, you can specify an interface
Right but that is probably useless since:
systemd-networkd-wait-online is a one-shot system service that waits for the network to be configured. By default, it will wait for all links it is aware of and which are managed by systemd-networkd.service(8) to be fully configured or failed, and for at least one link to gain a carrier.
Why useless? Suppose that you have eth0 and eth1 and that for 50% of boots, eth1 is configured and up before eth0 but you want the network to be considered up only when eth0 is configured and up. You can then use "-i eth0".
On Sun, 05 Nov 2017 14:33:42 -0500 Tom H wrote:
On Sun, Nov 5, 2017 at 12:41 PM, Francis.Montagnac@inria.fr wrote:
On Sun, 05 Nov 2017 12:24:15 -0500 Tom H wrote:
In the networkd case, you can specify an interface
Right but that is probably useless since:
systemd-networkd-wait-online is a one-shot system service that waits for the network to be configured. By default, it will wait for all links it is aware of and which are managed by systemd-networkd.service(8) to be fully configured or failed, and for at least one link to gain a carrier.
Why useless? Suppose that you have eth0 and eth1 and that for 50% of boots, eth1 is configured and up before eth0 but you want the network to be considered up only when eth0 is configured and up. You can then use "-i eth0".
Right. I meant that in most cases one wants the network to be considered up when all the interfaces (that should start at boot time) are configured.
PS: The systemd reference for this subject is there:
Running Services After the Network is up https://www.freedesktop.org/wiki/Software/systemd/NetworkTarget/
-- Francis
On Sun, Nov 5, 2017 at 3:02 PM, Francis.Montagnac@inria.fr wrote:
On Sun, 05 Nov 2017 14:33:42 -0500 Tom H wrote:
On Sun, Nov 5, 2017 at 12:41 PM, Francis.Montagnac@inria.fr wrote:
On Sun, 05 Nov 2017 12:24:15 -0500 Tom H wrote:
In the networkd case, you can specify an interface
Right but that is probably useless since:
systemd-networkd-wait-online is a one-shot system service that waits for the network to be configured. By default, it will wait for all links it is aware of and which are managed by systemd-networkd.service(8) to be fully configured or failed, and for at least one link to gain a carrier.
Why useless? Suppose that you have eth0 and eth1 and that for 50% of boots, eth1 is configured and up before eth0 but you want the network to be considered up only when eth0 is configured and up. You can then use "-i eth0".
Right. I meant that in most cases one wants the network to be considered up when all the interfaces (that should start at boot time) are configured.
You can probably set up a second (third, fourth, ...) "systemd-networkd-wait-online.service" for other interfaces. It's probably be more useful and practical if there were an option to set the interfaces that this service would use to enable "systemd-networkd-wait-online@ethX.service"
On 11/05/2017 01:59 PM, Tom H wrote:
On Sun, Nov 5, 2017 at 3:02 PM, Francis.Montagnac@inria.fr wrote:
On Sun, 05 Nov 2017 14:33:42 -0500 Tom H wrote:
On Sun, Nov 5, 2017 at 12:41 PM, Francis.Montagnac@inria.fr wrote:
On Sun, 05 Nov 2017 12:24:15 -0500 Tom H wrote:
In the networkd case, you can specify an interface
Right but that is probably useless since:
systemd-networkd-wait-online is a one-shot system service that waits for the network to be configured. By default, it will wait for all links it is aware of and which are managed by systemd-networkd.service(8) to be fully configured or failed, and for at least one link to gain a carrier.
Why useless? Suppose that you have eth0 and eth1 and that for 50% of boots, eth1 is configured and up before eth0 but you want the network to be considered up only when eth0 is configured and up. You can then use "-i eth0".
Right. I meant that in most cases one wants the network to be considered up when all the interfaces (that should start at boot time) are configured.
You can probably set up a second (third, fourth, ...) "systemd-networkd-wait-online.service" for other interfaces. It's probably be more useful and practical if there were an option to set the interfaces that this service would use to enable "systemd-networkd-wait-online@ethX.service"
I like that. Maybe something like a "systemd-networkd-wait-online.d directory that contains files named for the interfaces that have to be up and IP'd.
On Sun, 5 Nov 2017 14:19:47 -0800 Mike Wright wrote:
I like that. Maybe something like a "systemd-networkd-wait-online.d directory that contains files named for the interfaces that have to be up and IP'd.
Then you find everything stops working when you get another kernel update that breaks the unique interface naming scheme and changes the names of all the interfaces (which seems to happen with remarkable frequency).
How about just this: Wait for every damn interface that is marked as "start on boot". Ignore all the other ones.
Tom Horsley writes:
On Sun, 5 Nov 2017 14:19:47 -0800 Mike Wright wrote:
I like that. Maybe something like a "systemd-networkd-wait-online.d directory that contains files named for the interfaces that have to be up and IP'd.
Then you find everything stops working when you get another kernel update that breaks the unique interface naming scheme and changes the names of all the interfaces (which seems to happen with remarkable frequency).
How about just this: Wait for every damn interface that is marked as "start on boot". Ignore all the other ones.
I have a better idea. How about "network-wait-online.service, or whatever it's called, and whatever other services that need to be enabled, are enabled by default".
If a service, like privoxy, requires all interfaces to be up, then it simply needs to specify "network-wait-online" as a prerequisite, in its service file, and that's the end of it. Full stop. No other action should be needed. If nothing requires network-wait-online, well, nothing waits for all network interfaces to be up. And if something does, this gets done, without remembering whatever voodoo one needs to execute in order to make the system actually work.
Is that really such a novel concept?
If a package, such as privoxy, gets installed, and configured according to its instructions, but then it fails to start properly sometimes, then it's a bug that needs to be fixed.
On Sun, 05 Nov 2017 19:54:11 -0500 Sam Varshavchik wrote:
I have a better idea. How about "network-wait-online.service, or whatever it's called, and whatever other services that need to be enabled, are enabled by default".
If a service, like privoxy, requires all interfaces to be up, then it simply needs to specify "network-wait-online" as a prerequisite, in its service file, and that's the end of it. Full stop. No other action should be needed. If nothing requires network-wait-online, well, nothing waits for all network interfaces to be up. And if something does, this gets done, without remembering whatever voodoo one needs to execute in order to make the system actually work.
Is that really such a novel concept?
No. As I already said, this is exactly the goal of network-online.target,
Nevertheless, you will have to configure network-online.target if:
- you have more than one interface to start at boot - and use NetworkManager
-- Francis
On Sat, Nov 4, 2017 at 6:57 AM, Sam Varshavchik mrsam@courier-mta.com wrote:
privoxy.service most certainly has:
Wants=network-online.target After=network-online.target
...
However, privoxy just failed to start for me, after a reboot.
I was curious about this, so I went back to the beginning. I take back what I said earlier. This should work on a default Fedora system without any additional steps. I tested this on my own Fedora laptop, where the NetworkManager-wait-online service is in its default state, and the network link is provided by WiFi. I installed privoxy and configured it to listen on the IP address that would be assigned by DHCP, and rebooted the system. On boot, the service started after the network came online, just like you would expect (or, just like you should be able to expect, ideally).
I did some additional testing by creating a shell script, /usr/local/bin/ip-log, that runs "/usr/sbin/ip addr show | logger" and then executed it during startup by running "systemctl edit NetworkManager-wait-online". In the override file, I added two lines: [Service] ExecStart=/usr/local/bin/ip-log ... and rebooted. Boot records that most services start 14-16 seconds past the minute and that NetworkManager starts setting up. It takes six seconds to connect to WiFi and get an address from DHCP. At 22 seconds past the minute, the output of "ip addr show" is logged, and then privoxy starts.
So I'm not actually certain why this doesn't work on your system, and I'm interested in what comes of that bug.
-
Francis.Montagnac＠inria.fr -
Gordon Messmer -
Greg Woods -
Justin Moore -
Mike Wright -
Sam Varshavchik -
Samuel Sieb -
Tim -
Tom H -
Tom Horsley