elogind service starts after sound device initialization, causing permission failures

[erik9631]

Display Manager: SDDM
Desktop: KDE Plasma

On a fresh Void Linux installation with elogind, sound devices are created with incorrect permissions at boot, making them inaccessible to logged-in users. This occurs because elogind starts via D-Bus activation after udev has already processed sound devices.

Current Behavior:
At boot (before login):
crw------- 1 root root 116, 12 /dev/snd/controlC0

After manual udev trigger:
crw-rw----+ 1 root audio 116, 12 /dev/snd/controlC0

Void Linux ships elogind with only D-Bus activation enabled (/usr/share/dbus-1/system-services/org.freedesktop.login1.service)

No runit service is enabled by default (/var/service/elogind does not exist)

Boot sequence

1. udev processes sound devices early in boot
2. udev rules tag devices with uaccess (via /usr/lib/udev/rules.d/70-uaccess.rules
3. elogind helper (/usr/libexec/elogind/elogind-uaccess-command) should set ACLs
4. BUT elogind is not running yet (D-Bus hasn't activated it)
5. Devices get root:root 600 permissions
   User logs in → D-Bus now activates elogind → Too late, devices already processed

Sound devices remain inaccessible until manual udevadm trigger --subsystem-match=sound

Attempted Solutions:
ln -s /etc/sv/elogind /var/service/

Service fails to start because /etc/sv/elogind/run contains sv check dbus >/dev/null || exit 1, which fails with permission errors for non-root users. Meanwhile, D-Bus still auto-activates elogind, creating a conflict.

Option 2: Disable D-Bus activation + enable service

mv /usr/share/dbus-1/system-services/org.freedesktop.login1.service
/usr/share/dbus-1/system-services/org.freedesktop.login1.service.disabled
ln -s /etc/sv/elogind /var/service/

Result: SDDM fails to start resulting in no graphical login.

Any workarounds essentially lead me to either using rc.local with sleep and retrigger of udevadm, which is frankly a very bad solution, or rewriting the /etc/sv/sddm/run which I frankly think I shouldn't be doing.

I am not sure if this is even the correct repo to report this to, but this seems like a very obscure timing bug that should be probably looked into. If i am doing something wrong or have any suggestions how to fix this please let me know.

[Duncaen]

Why would elogind set any permissions other than the users access rights on login?

[Duncaen]

Doesn't look like it would change the mode or the group.

https://github.com/elogind/elogind/blob/c09b9caece0459ec56b234a87583e1bfac3c3271/src/uaccess-command/uaccess-command.c

elogind is kind of optional, the mode and groups should be set anyways, otherwise non elogind systems wouldn't work at all. Unless its elogind's uaccess stuff that is stopping the mode from being set.

dbus being required to start before udev seems pretty hard to achieve since it also runs in the initramfs.

[erik9631]

Olay let me try to explain it a bit clearer:

I get that elogind only adds user ACLs. I am specifically debugging audio issues in my install on my laptop and I'm seeing something puzzling: both the base permissions AND the ACLs are wrong at boot.

At boot (before any intervention):
crw------- 1 root root 116, 12 /dev/snd/controlC0

• Mode: 600 (should be 660)
• No ACLs (no + sign)

But after manually running udevadm trigger --subsystem-match=sound (with elogind running) I get the following:
crw-rw----+ 1 root audio 116, 12 /dev/snd/controlC0

Re-triggering udev rules after elogind is running fixes everything - not just the ACLs, but also the base root:audio 660 permissions. This suggests that whatever sets the base permissions is somehow dependent on elogind being available.

If traditional udev rules should be setting GROUP="audio", MODE="0660" independently of elogind, why does the initial processing at boot leave devices at kernel defaults (root:root 600)? And why does re-processing them later (when elogind is running) suddenly apply the correct base permissions?

I currently have this dirty workaround in rc.local

# Wait for elogind to be ready, then re-trigger sound devices
for i in $(seq 1 30); do
    if loginctl list-sessions >/dev/null 2>&1; then
        /usr/bin/udevadm trigger --subsystem-match=sound
        exit 0
    fi
    sleep 0.5
done

This works reliably, but it feels like papering over a deeper timing issue. What component should be setting the base permissions, and why does it only work when elogind is present?

[classabbyamp]

rc.local runs in stage 1, before any service is started, so not sure how putting something in there could interact with elogind

[Duncaen]

I get that elogind only adds user ACLs. I am specifically debugging audio issues in my install on my laptop and I'm seeing something puzzling: both the base permissions AND the ACLs are wrong at boot.

What I'm more hinting at is that it doesn't look like an elogind issue, unless if udev runs the rule that spawns elogind-uaccess-command it somehow stops any of the other udev actions, which doesn't seem like it is the case, but the udev documentation is not very clear.

I think a good first step in debugging this would be to either confirm or exclude elogind as cause, by uninstalling it and seeing whether it affects the device permissions on boot.

Next step is probably to enable more verbose logging in udev to try to find out why it won't apply the permissions by looking more closely at the logs and specifically order of events.

[Duncaen]

In the end even if the cause is elogind, the solution will probably not be to make sure dbus or elogind runs before udevd, that seems really unnecessary. elogind will be up when you log in and only then elogind is required to apply any acls anyways. If the processing stops because elogind-uaccess-command exits non-zero then the fix is to change that.

[erik9631]

Hello. Sorry for the long delay, my laptop's battery fried and had to replace it.

Either ways I did some debugging and this is what I found:
The cause seems to be a premature udevadm settle.

Stage 1 (/etc/runit/1) executes core-services:
/etc/runit/core-services/02-udev.sh processes devices:
Stage 2 (/etc/runit/2) starts immediately after:

Added logging to /etc/rc.local to capture device state:

#!/bin/sh
echo "=== RC.LOCAL START at $(cat /proc/uptime) ===" > /var/log/rclocal.log
ls -la /dev/snd/controlC0 >> /var/log/rclocal.log 2>&1
sleep 3
echo "=== RC.LOCAL AFTER SLEEP at $(cat /proc/uptime) ===" >> /var/log/rclocal.log
ls -la /dev/snd/controlC0 >> /var/log/rclocal.log 2>&1

Result after reboot:

=== RC.LOCAL START at 4.02 23.69 ===
ls: cannot access '/dev/snd/controlC0': No such file or directory

=== RC.LOCAL AFTER SLEEP at 7.02 47.21 ===
crw-rw---- 1 root audio 116, 12 Dec  5 09:53 /dev/snd/controlC0

At 4 seconds (when Stage 2 starts): Device does not exist

At 7 seconds (after 3-second delay): Device exists with correct root:audio 660 permissions

I initially believed this was an elogind timing issue because:
Manually running udevadm trigger --subsystem-match=sound after boot fixed the problem.

However, the real issue seems simpler: devices weren't being created at all initially. Re-triggering udev after boot succeeded only because enough time had passed for the hardware initialization to complete.

Currently I create A 3-second delay in /etc/rc.local.
This allows sound device creation to complete before services start, but it's a crude workaround that delays the entire boot process.

Why does udevadm settle return before sound devices are created?

Is this a hardware-specific timing issue?

Is there a better way to fix this?

This is my hw info:

=== System Info ===
Linux erik-laptop 6.12.58_1 #1 SMP PREEMPT_DYNAMIC Fri Nov 14 02:05:35 UTC 2025 x86_64 GNU/Linux

=== Audio Hardware ===
0000:00:1f.3 Multimedia audio controller: Intel Corporation Tiger Lake-LP Smart Sound Technology Audio Controller (rev 20)

=== Relevant Packages ===
ii alsa-lib-1.2.14_1                         Advanced Linux Sound Architecture (ALSA) library
ii alsa-pipewire-1.4.9_1                     Server and user space API to deal with multimedia pipelines - ALSA client library
ii alsa-ucm-conf-1.2.14_1                    ALSA Use Case Manager topology configurations
ii alsa-utils-1.2.14_1                       Advanced Linux Sound Architecture (ALSA) utilities
ii dbus-1.16.2_2                             Message bus system
ii dbus-libs-1.16.2_2                        Message bus system - shared libraries
ii dbus-x11-1.16.2_2                         Message bus system - X11 support
ii elogind-252.9_2                           Standalone logind fork
ii eudev-3.2.14_2                            Fork of systemd-udev (enhanced userland device daemon)
ii eudev-libudev-3.2.14_2                    Fork of systemd-udev (enhanced userland device daemon) - runtime library
ii eudev-libudev-32bit-3.2.14_2              Fork of systemd-udev (enhanced userland device daemon) - runtime library (32bit)
ii kdbusaddons-5.116.0_1                     KDE Convenience classes for DBus
ii kf6-kdbusaddons-6.19.0_1                  KDE Convenience classes for DBus
ii kpipewire-6.5.2_1                         Components relating to Flatpak 'pipewire' use in Plasma
ii libdbusmenu-glib-16.04.0_6                Library for passing menus over DBus
ii libdbusmenu-gtk3-16.04.0_6                Library for passing menus over DBus (GTK+3)
ii libdbusmenu-qt5-0.9.3+16.04.20160218_3    Library that provides a Qt5 implementation of the DBusMenu spec
ii libelogind-252.9_2                        Standalone logind fork - elogind library
ii libpipewire-1.4.9_1                       Server and user space API to deal with multimedia pipelines - pipewire library
ii libspa-alsa-1.4.9_1                       Server and user space API to deal with multimedia pipelines - alsa plugins
ii pipewire-1.4.9_1                          Server and user space API to deal with multimedia pipelines
ii qt5-dbus-5.15.11+20231124_6               Cross-platform application and UI framework (QT5) - DBus
ii qt6-dbus-6.10.0_3                         Cross-platform application and UI framework (QT6) - DBus
ii wireplumber-0.5.12_1                      Session and policy manager implementation for PipeWire

=== Enabled Services ===
NetworkManager  agetty-tty1  agetty-tty2  agetty-tty3  agetty-tty4  agetty-tty5  agetty-tty6  
bluetoothd  chronyd  dbus  polkitd  rtkit  sddm  udevd