https://bugs.kde.org/show_bug.cgi?id=514092
Matteo de Robertis <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] --- Comment #4 from Matteo de Robertis <[email protected]> --- Disclosure up front: I'm a user, not a developer, and the analysis in this comment was AI-assisted - I don't have the technical background to have written it myself. However, every log excerpt and command output below is real and comes from my own machine: I personally ran each command during a live stuck episode and verified the outputs to the best of my ability. Flagging this so you can weigh the interpretation accordingly; the raw data stands on its own, and I'm happy to re-run anything myself if something looks off. Not the OP, but I can reproduce this reliably on real hardware, and I managed to capture a full stuck episode live (journal, cgroup, fds). I believe the data below pins down the exact failure mechanism. Also an offer to test at the end. SETUP - CachyOS (Arch-based), Plasma 6.7.2, plasma-login-manager (plasmalogin.service), Wayland only - Kernel: linux-cachyos 7.1.3-1 (identical behaviour on 7.1.2-3, so not kernel-related) - seat0: RTX 5060 Ti (nvidia-open 610.43.02), DP monitor - seat1: AMD Ryzen 9950X3D iGPU (amdgpu), HDMI monitor, plus a dedicated xHCI USB controller - seat1 created via a static udev rule, present at boot before plasmalogin.service starts: SUBSYSTEM=="usb", KERNELS=="0000:12:00.0", TAG+="seat", ENV{ID_SEAT}="seat1" SUBSYSTEM=="input", KERNELS=="0000:12:00.0", TAG+="seat", ENV{ID_SEAT}="seat1" SUBSYSTEM=="drm", KERNEL=="card0", TAG+="seat", ENV{ID_SEAT}="seat1" BEHAVIOUR Intermittent, boot-time lottery in the greeter phase: on some boots both greeters come up and everything works; on others the greeter of one seat (not always the same one) never appears. Once both users are actually logged in, the dual-seat setup is fully stable - two independent kwin_wayland compositors, each DRM master on its own GPU; we've run a GPU-heavy game on each seat simultaneously without issues. The problem is confined to the greeter layer. CAPTURED EPISODE (seat1 greeter never appeared, seat0 user logged in normally) Timeline from the journals (journalctl -b -u plasmalogin.service and journalctl -b _UID=958, where 958 = the plasmalogin user): 23:17:27 - the daemon adds two displays and starts TWO greeter sessions (helpers PID 1137 for seat1, PID 1138 for seat0), both as user plasmalogin: plasmalogin[1135]: Using VT 1 plasmalogin[1135]: Display server started. / Socket server started. / Greeter starting... (x2) plasmalogin-helper[1138]: pam_unix(plasmalogin-greeter:session): session opened for user plasmalogin(uid=958) plasmalogin-helper[1137]: pam_unix(plasmalogin-greeter:session): session opened for user plasmalogin(uid=958) plasmalogin[1135]: Greeter session started successfully (x2) 23:17:27 - meanwhile, inside the single [email protected], systemd starts ONE instance of each greeter unit (they are singleton per-UID user units): systemd[1141]: Starting KDE Window Manager (Login Manager Version)... kwin_wayland[1182]: Accepting client connections on sockets: QList("wayland-0") systemd[1141]: Started KDE Window Manager (Login Manager Version). systemd[1141]: Started Plasma Login. systemd[1141]: Reached target plasma-login-wayland.target. 23:17:28 - the single greeter UI connects and serves seat0. Note: ONE Connect for TWO "Greeter session started successfully": plasmalogin[1135]: Message received from greeter: Connect 23:17:34 - the seat0 user logs in (Message received from greeter: Login, session started on VT 2). 23:17:39 - systemd tears the whole greeter target down: systemd[1141]: Stopped target plasma-login-wayland.target. systemd[1141]: Stopped Plasma Login. systemd[1141]: Stopped KDE Window Manager (Login Manager Version). >From this point on, seat1 is starved forever: its helper (1137) and its startplasma-login-wayland (1151) are still alive and waiting, but the user units they need (plasma-login-kwin_wayland.service, plasma-login.service) are singletons that already ran for seat0 and have now been stopped. No compositor is ever created for seat1 -> permanently black screen, while logind considers everything fine. STATE DURING THE HANG (>10 minutes in) loginctl list-sessions - the seat1 greeter session (c2) is still "alive": SESSION UID USER SEAT LEADER CLASS TTY 1 958 plasmalogin - 1141 manager-early - 2 1000 matteo seat0 1301 user tty2 3 1000 matteo - 1307 manager - c2 958 plasmalogin seat1 1137 greeter - systemd-cgls /user.slice/user-958.slice - session-c2.scope contains only the helper and startplasma-login-wayland; NO compositor, and no greeter services under [email protected] anymore (only dbus/pipewire/wireplumber remain): |-session-c2.scope |-1137 /usr/lib/plasmalogin-helper ... --start /usr/bin/startplasma-login-wayland --user plasmalogin --greeter |-1151 /usr/bin/startplasma-login-wayland pgrep -a kwin_wayland - the only compositor on the whole system is the seat0 user session's kwin (uid 1000). The greeter kwin (1182) is gone. The greeter user units themselves, queried inside the plasmalogin user manager during the hang (systemctl --user [email protected] status ...): o plasma-login-kwin_wayland.service - KDE Window Manager (Login Manager Version) Loaded: loaded (/usr/lib/systemd/user/plasma-login-kwin_wayland.service; static) Active: inactive (dead) o plasma-login.service - Plasma Login Loaded: loaded (/usr/lib/systemd/user/plasma-login.service; static) Active: inactive (dead) Both dead while seat1's startplasma-login-wayland is still waiting for them - and being static units, nothing will ever start them again on its own. The blocked helper (1137) sits in ppoll(..., timeout=NULL) (confirmed with strace -f -tt in a previous episode of the same failure: no events over 15+ seconds, genuinely idle, not retrying). Its fds are an eventfd, a socketpair to its child, the log socket to the plasmalogin daemon, and the journal socket - i.e. it is waiting for the child to report a session that can never come up. READING This matches comment #2's single-UID analysis, and adds the second half of the mechanism: it's not just that only one greeter-compositor instance can exist for the shared plasmalogin UID - it's that after the winning seat's login, the plasma-login-wayland.target teardown makes the loser's starvation PERMANENT. Which seat wins appears to be a startup race, hence the boot-to-boot lottery (sometimes both seats do get served, presumably when the timing lines up differently). OFFER Comment #3 mentioned a WIP targeting 6.7 - is that branch/MR still alive and public anywhere? I have a permanent, real dual-GPU multiseat machine (nvidia-open + amdgpu, separate monitors/inputs) available for testing any WIP or MR for this, and can provide further logs or run instrumented builds if useful. -- You are receiving this mail because: You are watching all bug changes.
