Tom H writes:
"NetworkManager-wait-online.service" has: <begin> After=NetworkManager.service Wants=network.target Before=network.target network-online.target </end> Perhaps you should replicate that in "wait-for-network.service" for it to behave as you intend it. I assume that you can replicate "After=NetworkManager.service" with "After=network.service" even though your network's being brought up by "/etc/rc.d/init.d/network".
s/even though/because/ Ok, I tried the following variation: [Unit] Description=Wait for network ports to be initialized Before=network.target network-online.target After=network.service Wants=network.target [Service] Type=oneshot ExecStart=/root/bin/wait-for-network [Install] WantedBy=multi-user.targetWith this, the first reboot initialized all servers properly, and the console logging during the boot went back to what it was about a month or two ago, before everything went off the rails.
What do you have in "/root/bin/wait-for-network"?
Nothing particularly exciting. I'll attach it below. But whatever it does or does not have, it should not affect the order in which systemd starts processes. It can't possibly affect the order in which systemd starts processes. It has no means of controlling the order; yet, with the previous service file, with having just a "Before=network.target", systemd was clearly launching a different service that stated "After=network.target", before this one finished. Which was broken.
On the last boot, the following script logged that all interfaces were already up when it started. Previously, it showed that only lo0 was up, and the rest came up after it waited ten seconds. So the difference now is clearly because of "After=network.service", but that alone doesn't explain it. Even without it, this service doesn't officially start, according to the documented specification of a one-shot service, until network.service finished bringing up all the interfaces.
So that leaves the addition of "Wants=network.target". It apparently has an effect on the ordering of services that get started. Now, you read its description, in systemd's documentation and tell me if it says anything about controlling the order of services. The plain reading of the documentation only suggests that this controls what gets started, and not which order anything gets started with.
After grepping around, it became even more obvious how brain-dead systemd is. The new service that I added is the only service that specifies "Wants=network.target". None of the stock Fedora services – including the ones that fail to start properly until the network connections are up – specify "Wants=network.target". No Fedora server package, that I have installed, specifyis "Wants=network-online.target" either; but I have some non-Fedora packages that specify "Wants=network-online.target". And until I installed this custom service, nothing else wanted network.target either.
So… Looks like the bug is as follows. The system comes up with systemd configured to bring up multi-user.target. But unless something explicitly specifies Wants=network.target, systemd is going to completely ignore this target, and completely ignore all Before or After network.target specification, from any service that it is starting, and ignore any obvious dependencies that result from Before or After network.target. All without giving any hint as to what it's doing.
As I said: this used to work, at least for me, reliably, until about a month or two ago, and I see that there have been a couple of systemd updates since. I can almost hear someone already bleating "this is how systemd is designed to work, and the problem is with incorrect service files".
Presuming that my guess as to what the bug is, is correct: this is a bunk answer. Either this was a major change in systemd's behavior, recently, or not. If not: 1) systemd documentation is crap, and this should've been documented under in the "Wants" documentation a long time ago, 2) systemd just broke everything, without bothering to announce this major change in behavior. And this is also crap.
But this should not surprise anyone. Recall, earlier this year, Linus calling out systemd's maintainer for pulling the exact same kind of a stunt: breaking something, in this case a kernel boot with the "debug" option, and then acting as if it's the kernel's problem to solve. Same exact snobbery and arrogance.
Well, anyway, here's my script, FWIW, which is really a moot point; since by using After=network.service it's not really necessary, any more.
#! /usr/bin/perl
use IO::File;
use strict;
use warnings;
open(LOG, ">/tmp/wait-for-network.log");
sub get_ifconfig {
my $fh=IO::File->new;
open($fh, "-|", "/usr/sbin/ifconfig") or exit 0;
my $up=0;
print LOG ((scalar localtime) . "\n");
while (defined ($_=<$fh>))
{
chomp;
next unless /^([^ ]+):/;
my $ifname=$1;
my $found=0;
while (defined ($_=<$fh>))
{
chomp;
last unless /^ /;
$found=1 if /^ +inet/;
}
print LOG "Interface: $ifname is " . ($found ? "up":"down") . "\n";
return 0 unless $found; # Some network interface does not have an IP address, yet
++$up unless $ifname eq "lo";
}
return $up;
}
foreach (1..60)
{
exit 0 if get_ifconfig;
sleep(5);
}
Attachment:
pgpEkWB9fdxLo.pgp
Description: PGP signature
-- users mailing list users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
