FS#37112 - [dhcpcd] forks to background too early on dual-stack connections
Attached to Project:
Arch Linux
Opened by Radu Potop (wooptoo) - Saturday, 28 September 2013, 18:19 GMT
Last edited by Doug Newgard (Scimmia) - Wednesday, 13 May 2015, 22:27 GMT
Opened by Radu Potop (wooptoo) - Saturday, 28 September 2013, 18:19 GMT
Last edited by Doug Newgard (Scimmia) - Wednesday, 13 May 2015, 22:27 GMT
|
Details
I have a dual-stack internet connection and I use the
dhcpcd@eth0.service
at bootup. Dhcpcd forks to background right after the DHCPv6
lease is obtained, causing the network.target to appear as
ready. This in turn causes some services that depend on
internet connection to fail. Then it finally gets the DHCPv4
lease.
The attached log clears things up: dhcpcd starts dhcpcd gets an DHCPv6 lease dhcpcd forks to background, causing the network to appear as ready services such as minidlna and transmission fail dhcpcd finally gets DHCPv4 lease The service is started with `dhcpcd -q -w eth0` so in theory it *should* wait for a lease. This does not happen when starting dhcpcd manually from the command line after booting. |
This task depends upon
http://roy.marples.name/projects/dhcpcd/ticket/242
dhcpcd cannot possible know which protocols are needed for a clean boot, so it's behaviour is to fork once one of the protocols complete.
However, it's obvious that the user might be able to specify a preference, so this patch was added over a week ago:
http://roy.marples.name/cgi-bin/gitweb.cgi?p=dhcpcd.git;a=commit;h=fbfa80330d336b8cae03c6da4e67535dc25b7ee6
Hopefully a new dhcpcd release soon.
It will fork to background on IPv4 connection, BUT it will also get an IPv6 address as soon as it is available.
This IS actually the behaviour that I want, but it's funny that it also gets an IPv6 address, when I specified that it should get IPv4 only.
Can this happen because of SLAAC or maybe it is a bug in dhcpcd?
By default dhcpcd lets the kernel handle that still, but it will request an RA. As you're using the -4 that, it shouldn't be requesting the RA via an RS but equally dhcpcd won't stop the kernel doing that either.
Using wicd to control my network connection here. wicd starts dhcpcd, which gets an IPv6 address and forks to background. wicd then kills dhcp as it did not find a valid IPv4 address on the interface. My solution is to simply add
waitip 4
to dhcpcd.conf. This makes dhcpcd wait for an IPv4 address before forking to background. Probably this also works for services and their dependencies.
FS#41216. As it appears the main bug here is taken care of, I'm going to close this one.