Add option to make dhcpcd non-blocking

[cprussin]

Issue description

dhcpcd has the -b option as an alternative to -w to make it go into the background immediately, without waiting until an IP address is resolved. I was surprised to notice that the dhcpcd module doesn't offer any option to use -b instead of -w. This results in my user sessions having to wait until dhcpd has received an IP before they can start, causing my startup to take much longer than it would otherwise.

I'd be happy to submit a PR to add the option, but I was quite surprised it didn't already exist and thought it might have been intentional, so I figured I'd open a ticket to discuss first. Is there a better way to solve this problem? Would this be an acceptable change?

Steps to reproduce

Erm...

Technical details

Please run nix-shell -p nix-info --run "nix-info -m" and paste the
results.

$ nix-shell -p nix-info --run "nix-info -m"
 - system: `"x86_64-linux"`
 - host os: `Linux 4.14.79, NixOS, 18.09.1228.a4c4cbb613c (Jellyfish)`
 - multi-user?: `yes`
 - sandbox: `yes`
 - version: `nix-env (Nix) 2.1.3`
 - nixpkgs: `/nix/var/nix/profiles/per-user/root/channels/nixos`

[worldofpeace]

I am not opposed to introducing this option, and it seems Arch Linux does this by default.

[cprussin]

In the last few days, I've done a bit more research, and I now think the problem here is actually about unit ordering.

I think it makes sense for dhcpcd.service to block network-online.target, however as it is configured, it blocks network.target (see here).

I've solved this locally by adding systemd.services.dhcpcd.before = lib.mkForce [ "network-online.target" ];. Since systemd-user-sessions blocks on network.target, this is sufficient. However, I notice that multi-user.target (and thus graphical.target) blocks on network-online.target as well (I'm not sure where this is coming from, I haven't found any unit setting up a Before or After that would cause this). This hasn't posed a problem for me, but it sure seems wrong.

So essentially it seems to me like network.target and network-online.target are used inconsistently, and certainly not consistent with the systemd docs, which specifically mention that:

Units that strictly require a configured network connection should pull in network-online.target (via a Wants= type dependency) and order themselves after it. This target unit is intended to pull in a service that delays further execution until the network is sufficiently set up. What precisely this requires is left to the implementation of the network managing service.

Note the distinction between this unit and network.target. This unit is an active unit (i.e. pulled in by the consumer rather than the provider of this functionality) and pulls in a service which possibly adds substantial delays to further execution. In contrast, network.target is a passive unit (i.e. pulled in by the provider of the functionality, rather than the consumer) that usually does not delay execution much. Usually, network.target is part of the boot of most systems, while network-online.target is not, except when at least one unit requires it. Also see Running Services After the Network is up for more information.

I believe the correct fix here is:

1. Change the dhcpcd (and any other similar package) unit definition to block network-online.target instead of network.target.
2. Fix the dependency between multi-user.target and network-online.target.

If some of you lovely more experienced nixos contributors can weigh in and let me know if this plan sounds right (and help me track down whatever is enforcing that multi-user.target is after network-online.target), I'm happy to whip up a PR.

[lheckemann]

This has been discussed in #44524 already

[balsoft]

I think what should be done is actually systemd.services.dhcpcd.serviceConfig.Type = "simple"; as I don't think dhcpcd forks to background at all.

[lheckemann]

@balsoft dhcpcd(8):

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.

[cprussin]

Looks like this is a dupe of the (now closed) #60900