Nixpkgs: systemd-udev-settle.service is overused

Created on 9 Nov 2019 · 12Comments · Source: NixOS/nixpkgs

Describe the bug
Related: #53446

Using systemd-udev-settle "is not recommended" (man 8 systemd-udev-settle.service). Nevertheless, we have quite a few services depend on it:

$ rg -l systemd-udev-settle
nixos/tests/misc.nix
nixos/modules/hardware/ksm.nix
nixos/modules/security/lock-kernel-modules.nix
nixos/modules/virtualisation/openvswitch.nix
nixos/modules/virtualisation/libvirtd.nix
nixos/modules/virtualisation/lxd.nix
nixos/modules/virtualisation/anbox.nix
nixos/modules/tasks/kbd.nix
nixos/modules/services/x11/xserver.nix
nixos/modules/services/hardware/tcsd.nix
nixos/modules/services/hardware/brltty.nix
nixos/modules/services/networking/dhcpcd.nix
nixos/modules/services/scheduling/atd.nix
nixos/modules/services/hardware/trezord.nix
nixos/modules/services/hardware/acpid.nix
nixos/modules/system/boot/networkd.nix
nixos/modules/system/boot/systemd.nix
nixos/modules/tasks/filesystems/zfs.nix

On some systems/kernels (e.g. mobile-nixos kernels, cc @samueldr @kirelagin), this can cause boot to wait for systemd-udev-settle to time out, which is no fun.

Expected behavior
Services depend only on the devices that they need, either by waiting for them themselves or by depending on systemd's relevant .device unit.

Metadata

system: "aarch64-linux"
host os: Linux 3.18.71, NixOS, 19.09.941.27a5ddcf747 (Loris)
multi-user?: yes
sandbox: yes
version: nix-env (Nix) 2.3
channels(root): "nixos-19.09.941.27a5ddcf747"
nixpkgs: /nix/var/nix/profiles/per-user/root/channels/nixos

bug

Source

lheckemann

All 12 comments

@lheckemann Should we merge https://github.com/NixOS/nixpkgs/pull/25311 for display-manager?
TBH, I've been running a config to disable it for a while now.

worldofpeace on 9 Nov 2019

As of now...

Removed from:

nixos/modules/services/scheduling/atd.nix    
nixos/modules/services/x11/xserver.nix
nixos/modules/tasks/kbd.nix

Added to:

nixos/modules/config/console.nix

bqv on 4 Apr 2020

❤1

@bqv Thanks. Is the one for xserver.nix in 20.03?

worldofpeace on 4 Apr 2020

@worldofpeace It is not, only the removal from tasks/kbd.nix and the addition is

bqv on 4 Apr 2020

Had to re-add it to GDM: f74f2f354866c828248a419ef9a2cbddc793b7f9

jtojnar on 6 Apr 2020

@jtojnar maybe gdm can depend on any DRI device instead of the global systemd-udev-settle.service? This would probably require some udev rules, but be a lot more elegant IMHO.

lheckemann on 6 Apr 2020

But display-manager.service should already run After systemd-logind.service, which contains:

ExecStartPre=-/nix/store/ijka1p5ndsjq60frdhlq5il0s9mgyypj-kmod-26/sbin/modprobe -abq drm

I would expect that to work, unless we are affected by https://github.com/systemd/systemd/issues/14322.

jtojnar on 6 Apr 2020

But the kernel module being loaded doesn't necessarily imply the device being available, does it?

lheckemann on 6 Apr 2020

It's possible to remove it from dhcpdc.service? Arch just relies on network.target (https://git.archlinux.org/svntogit/packages.git/tree/trunk/dhcpcd.service?h=packages/dhcpcd)

Looking at the commit does not explain why it was added (https://github.com/NixOS/nixpkgs/commit/4c6171c173ef5e50ecbbc1157c035147462ee721) @srhb

asbachb on 23 Apr 2020

Hi @asbachb . Sorry, I can't remember that far back, but there's some notes in the PR which brought in the commit, maybe it's helpful. It looks like I wasn't strictly happy with it even back then. :)

https://github.com/NixOS/nixpkgs/pull/45421

srhb on 24 Apr 2020

👍1

Hello, I'm a bot and I thank you in the name of the community for opening this issue.

To help our human contributors focus on the most-relevant reports, I check up on old issues to see if they're still relevant. This issue has had no activity for 180 days, and so I marked it as stale, but you can rest assured it will never be closed by a non-human.

The community would appreciate your effort in checking if the issue is still valid. If it isn't, please close it.

If the issue persists, and you'd like to remove the stale label, you simply need to leave a comment. Your comment can be as simple as "still important to me". If you'd like it to get more attention, you can ask for help by searching for maintainers and people that previously touched related code and @ mention them in a comment. You can use Git blame or GitHub's web interface on the relevant files to find them.

Lastly, you can always ask for help at our Discourse Forum or at #nixos' IRC channel.