Change:
wantedBy = [ "multi-user.target" ] ++ optional (!hasDefaultGatewaySet) "network-online.target"; wants = [ "network.target" "systemd-udev-settle.service" ]; <del> before = [ "network.target" ]; </del> <ins> before = [ "network-online.target" ]; </ins> after = [ "systemd-udev-settle.service" ]; # Stopping dhcpcd during a reconfiguration is undesirable

Discussion:
At boot, the login window must wait for /run/nologin to be removed (see pamnologin(8)) . This happens when systemd launches , which removes when it is started, and creates it when it is stopped. Under the default NixOS configuration, there is a significant delay in this process due to systemd waiting for to fork. The root cause is a gross hack in upstream systemd, which seeks to provide clean termination of inbound SSH sessions by ordering after : fixes This was done so that at shutdown, systemd will kill the SSH sessions (by stopping ) before bringing down the network. The inevitable problem is that now, local logins must wait at boot for , which is silly. It wouldn't matter much, except that NixOS has configured to block instead of just : It appears that this issue has gone largely unnoticed because other distros either don't use dhcpcd, use it in background mode, ignore the /run/nologin mechanism (which appears to be something of a relic - I can't find much discussion about it), or have blocking only , in which case login will be blocked only by a few service initializations that don't take very long. Ordered best to worst, in my opinion. Any of these should be OK for home use. (after rebuild do ) systemd-networkd instead: systemd.network.networks = { internet0 = { matchConfig = { Name = "&lt;device"; }; networkConfig = { DHCP = "ipv4"; }; }; };&lt;deviceeth0 or whatever) time out fast, and : Seems to work when multiple interfaces are available. Man page says I don't know what will happen in that case. fork to background immediately The nixos module doesn't export the generated conf path, so it has to be found manually () and kept updated. Or replace it with a separate one. (how?) - sounds like a Bad Idea recommended: attempting to reconfigure the ordering. It "works", but renders inactive, presumably due systemd barfing on a cyclic dependency. Override the ordering dependency somehow See also , Boot a NixOS machine with networking and dhcp(cd) enabled, but no network connection available. The machine should boot and present a login window just as quickly as with the network available. User is presented with a black screen for up to 30 seconds before login window appears.

Actually, it seems this has been reported by Arch users before:
cc
I don't think this has been fixed. Many people seem to describe slow boot times due to dhcpcd in and I personally still have this issue.
It should no longer because of , what is your biggest time consumer in ?
If I run , dhcpcd.service, is the top service. Same with the plot. (which closed this issue), just changed dhcpcd to be before instead of which in the end still means that we have to wait for dhcpcd to start.
Ok. But does your multi- depend on it? dhcpcd beeing slow should not be a problem if nothing else depends on it.
Yes depends on . I am not quite sure why that is the case though.
I tracked this down to from However wantedBy should only trigger the target and not wait for it, no?
Yes (AFAIK). Before my last comment, I also looked around for the source of this but because all I could find where wantedBy "things", I thought it must be related to something else. But the commit reverts, , mentions decrease in boot time, so I guess it does wait.
I actually disabled it in the past:
should fix this (when it is finished).
I suppose multi- is only marked as done when the online is and the requires the multi-
the PR was closed but you can re-open it and do
If does not pull in , then you're telling systemd not to bother bringing up the network. I doubt that's what you want. Correct on both counts :) The output of isn't diagnostic here. It shows the complete time taken to reach , but the system can be up and usable minutes before that. Reaching means that all desired services are running, not just those that are required to use the machine. You could try looking at the output of and . But I note that points the finger at . Have you already ruled that out?
Thanks for clarification.
I'm experiencing an issue like this, but I'm having trouble following the history a little bit. My understanding is that used to delay when it should have been delaying , but that this was fixed in . I don't use to launch my window manager, so I'm investigateding .

Based on , I think the issue is that is blocking when, like , it should be blocking . So the actual issue is that has to run , but this should be changed to ?
Those services come from: . I think they just setup static network interfaces, which is usually fine for and should just wait for local network interfaces to be present rather than waiting for external dhcp requests. Also see:
Sorry for the noise, I realized the issue was I had a line even though this is a laptop and only has when ethernet is plugged in. So it waits for to appear and times out on every boot. Removing that fixed the problem.
I marked this as stale due to inactivity. &rarr;
Another attempt to get rid of the patch is here: , and I expect this one will not be reverted. I think we can close this, even though dhcpcd is itself still slow due to conflict detection (there might be an option to turn that off, but you could also set which also fixes this).