8:57 a.m.
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.
10:14 a.m.
On Sat, Nov 4, 2017 at 9:51 AM, Tom Horsley <horsley1953(a)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
9:29 p.m.
On Sat, Nov 4, 2017 at 11:14 AM, Greg Woods <woods(a)ucar.edu> wrote:
On Sat, Nov 4, 2017 at 9:51 AM, Tom Horsley
<horsley1953(a)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".
9:27 p.m.
On Sat, Nov 4, 2017 at 9:57 AM, Sam Varshavchik <mrsam(a)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?
11:48 p.m.
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.
12:56 a.m.
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.
7:36 a.m.
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.
9:46 a.m.
On Sun, Nov 5, 2017 at 8:36 AM, Sam Varshavchik <mrsam(a)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.
4:09 p.m.
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
7:10 p.m.
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.
5:26 a.m.
On Sun, Nov 5, 2017 at 8:10 PM, Sam Varshavchik <mrsam(a)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."
6:07 a.m.
Tom H writes:
On Sun, Nov 5, 2017 at 8:10 PM, Sam Varshavchik
<mrsam(a)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.
4:35 a.m.
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@localhost ~]$ uname -rsvp
Linux 4.13.9-200.fc26.x86_64 #1 SMP Mon Oct 23 13:52:45 UTC 2017 x86_64
Boilerplate: All mail to my mailbox is automatically deleted.
There is no point trying to privately email me, I only get to see
the messages posted to the mailing list.
A positive attitude is worth the effort if it annoys enough people.
6:05 a.m.
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?
9:39 a.m.
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.
--
[tim@localhost ~]$ uname -rsvp
Linux 4.13.9-200.fc26.x86_64 #1 SMP Mon Oct 23 13:52:45 UTC 2017 x86_64
Boilerplate: All mail to my mailbox is automatically deleted.
There is no point trying to privately email me, I only get to see
the messages posted to the mailing list.
Ha ha ha ha...
(I couldn't think of a good joke, so I supplied a laugh track, instead.)
7:26 p.m.
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(a)lists.fedoraproject.org
To unsubscribe send an email to users-leave(a)lists.fedoraproject.org
6:15 a.m.
On Sun, Nov 5, 2017 at 12:48 AM, Sam Varshavchik <mrsam(a)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?
7:52 a.m.
Tom H writes:
On Sun, Nov 5, 2017 at 12:48 AM, Sam Varshavchik
<mrsam(a)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.
8:18 a.m.
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.
8:40 a.m.
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.
4:14 p.m.
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.
8:46 a.m.
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
10:05 a.m.
On Sun, Nov 5, 2017 at 8:52 AM, Sam Varshavchik <mrsam(a)courier-mta.com> wrote:
Tom H writes:
> On Sun, Nov 5, 2017 at 12:48 AM, Sam Varshavchik <mrsam(a)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.
10:22 a.m.
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(a)gmail.com> wrote:
On Sun, Nov 5, 2017 at 8:52 AM, Sam Varshavchik
<mrsam(a)courier-mta.com>
wrote:
> Tom H writes:
>> On Sun, Nov 5, 2017 at 12:48 AM, Sam Varshavchik <mrsam(a)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(a)lists.fedoraproject.org
To unsubscribe send an email to users-leave(a)lists.fedoraproject.org
11:24 a.m.
On Sun, Nov 5, 2017 at 11:22 AM, Justin Moore <justin.nonwork(a)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".
11:41 a.m.
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(a)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 :-(
--
Francis.Montagnac(a)inria.fr, SIC-SAM, Tel: (33) 04 92 38 79 11, Bur: C111
INRIA Sophia, 2004, route des Lucioles - BP 93 06902 Sophia Antipolis Cedex
1:33 p.m.
On Sun, Nov 5, 2017 at 12:41 PM, <Francis.Montagnac(a)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".
2:02 p.m.
On Sun, 05 Nov 2017 14:33:42 -0500 Tom H wrote:
On Sun, Nov 5, 2017 at 12:41 PM, <Francis.Montagnac(a)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
3:59 p.m.
On Sun, Nov 5, 2017 at 3:02 PM, <Francis.Montagnac(a)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(a)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(a)ethX.service"
4:19 p.m.
On 11/05/2017 01:59 PM, Tom H wrote:
On Sun, Nov 5, 2017 at 3:02 PM, <Francis.Montagnac(a)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(a)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(a)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.
4:33 p.m.
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.
6:54 p.m.
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.
1 a.m.
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
5:17 p.m.
On Sat, Nov 4, 2017 at 6:57 AM, Sam Varshavchik <mrsam(a)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.
2355
days inactive
2358
days old
34 comments
10 participants
participants (10)
-
Francis.Montagnac＠inria.fr -
Gordon Messmer -
Greg Woods -
Justin Moore -
Mike Wright -
Sam Varshavchik -
Samuel Sieb -
Tim -
Tom H -
Tom Horsley