Making systemd-networkd
really skip trying IPv6 on your networks
I originally switched from Fedora's traditional (or old)
/etc/sysconfig/network-scripts/ifcfg-*
to systemd's networkd stuff
partly in order to get faster system boots.
That makes it ironic that for the past while (at least months), my
system has been stalling during boot for 15 to 20 seconds or so
while it waits for something about the networking to report in
that it's fully ready.
(The direct stall was caused by the systemd-networkd-wait-online service, which is known in your console messages as 'Wait for Network to be Configured' and which runs the systemd-networkd-wait-online program, which works in relatively mysterious ways.)
For a long time I just shrugged and ignored the issue, but the other
day I got irritated enough to finally look at the journal with
journalctl
to see if there was anything obvious there about what
was waiting for what. At that point I found some interesting log
messages to the effect of:
Sep 27 09:53:46 hawkwind.cs systemd-networkd[1720]: p2p1: Starting DHCPv6 client after NDisc timeout failed: Invalid argument
This made my eyebrows go right up because I specifically have DHCP
disabled for all of my networks. It's right there in the .network
files:
[Network] DHCP=no
All of my networks have DHCP disabled and statically configured IPv4 addresses, and we don't do IPv6. Systemd's networkd shouldn't be trying to do IPv6 at all (if I ever do IPv6 on my office machine, it will be statically configured).
If you search for this message on the web, you will find some interesting bug reports. These are not entirely clear but they did tell me what the workaround is, which is to set a magic setting that stops this behavior. That setting is:
IPv6AcceptRouterAdvertisements=no
(It goes in the [Network]
section too. Note that you may find
some documentation that shortens the name of this parameter, which
doesn't work in a .network
file.)
This is probably going to have additional effects if you want to actually use IPv6 (with statically configured IPv6 addresses), but I don't currently want to do that on my work machine (my home machine would be a different matter, but luckily I don't use systemd's networkd on the home machine).
Looking briefly at the systemd source, what appears to be happening is that systemd is sending out ICMPv6 router solicitations (it appears to try three times with a four second pause between each try). If it doesn't get any replies, which of course it won't since we don't have any IPv6 routers, it proceeds to this NDisc timeout, where it tries to start a DHCPv6 client but fails (or times out and the specific error message doesn't reflect this).
I don't know enough about IPv6 networking to say whether this is sensible or not in general. It is undeniably a mistake on IPv4 only networks, since it inserts a clear stall in boot in normal configurations. Given that one of systemd's entire purposes is to boot your system faster, well, I'll let you draw your own conclusions.
(Probably some systemd people will now show up to tell me that I'm doing it wrong and that all of my programs and daemons should be prepared for addresses to come and go dynamically and so I should never have been using anything that actually 'waited for networking to be up', whatever that means (this is a systemd FAQ). I have reactions to that idea but they do not fit in this entry.)
|
|