If dhcpcd forks immediately and systemd thinks the network is ready, isn't it possibile that programs needing to bind to an address may randomly fail if the interface is not up yet?
I'd say it's better to just disable ARP checking, this saves a significant number of seconds and should be safe in most cases.

I am not really an expert, but ArchLinux starts dhcpcd with the -b flag by default: Here is the ArchLinux dhcpcd.service file. Additionally, I kept the standard behaviour - I only added the option of forking to the background, which actually might be helpful in many cases.

There is a relevant discussion at #50930

dhcpcd actually has various other possible configurations regarding waiting:

man dhcpcd:

If any interface reports a working carrier then dhcpcd will try and obtain a lease before forking to the background, otherwise it will fork right away. This behaviour can be modified with the -b, --background and -w, --waitip options.

--waitip=[4 | 6]
Wait for an address to be assigned before forking to the background. 4 means wait for an IPv4 address to be assigned. 6 means wait for an IPv6 address to be assigned. If no argument is given, dhcpcd will wait for any address protocol to be assigned. It is possible to wait for more than one address protocol and dhcpcd will only fork to the background when all waiting conditions are satisfied.

So perhaps we should have a multiway option e.g.

dhcpcd.wait = one of {"never", "if-network-up", "any", "ipv4", "ipv6", "both"}

See also #44524 (comment)

@Mic92 The dhcpcd unit already activates network-online.target if a lease has been obtained but unfortunately does this on IPv6 or IPv4. So network-online.target may be activated without an IPv4 default route if IPv6 succeeds first.

Dhcpcd can be configured to either wait for IPv4 or IPv6 but this will break IPv4-only or IPv6-only systems. Not sure what we should do here without introducing new options and rethinking the NixOS networking autoconfiguration logic.

See also #35567 (comment)

FTR, been using this for a while. There may be other issues around this but startups are much better on certain machines.

Yeah, can we marge this please?

There has been no response to my feedback above. I suggest not adding half-baked options since it causes user friction if they are removed later :)

Note also that the unit ordering issue has been fixed, so you shouldn't be experiencing delayed starts anyway unless you're still on 19.03, in which case you could employ any of various workarounds.

ping @bene1618

I tried to implement @gloaming 's suggestion. I do not really understand if the standard behaviour (without any of the options) differs from "waitip", so I left out the "if-network-up" option.

As I understand it, the default behaviour is equivalent to background if your ethernet is unplugged and your wifi is unpowered, and equivalent to waitip otherwise. The point is that you can't hope to get a connection if you're not plugged in, so there's no point waiting.

Now that we have dhcpcd bound to network-online.target, defaulting to waitip is sensible.

if-network-up was silly of me, it should have been if-carrier-up or just default. Since the option is an enum, I guess we ought to include it or a user won't be able to select the default behaviour at all.

Updates?

I seem to have closed the pull request accidentally by doing something wrong with the push of the squashed commit. Now I don't see how I can reopen it again. Github claims that there are no new commits on the bene1618:master branch, but there is one: bene1618@0767de3

Could someone maybe help me what I have to do now?

Not sure, but you can also just open a new PR. Generally I also suggest creating a new branch for every PR

Not sure, but you can also just open a new PR. Generally I also suggest creating a new branch for every PR

Yep 👍

@bene1618 You really shouldn't use the master branch as per our contributing docs.

git checkout -b new-branch-name

and PR.

Yes, I also realized that shortly after I had opened this pull request. I have now opened a new one at #78745.