Logout leaves DRM device in a bad state; GDM greeter can't get display access, GDM crashes

[PulseRH]

Bug

Logging out of a driftwm session (udev backend, real hardware, GDM as the display manager) leaves the DRM device in a state where GDM's respawned greeter can't get display access, which cascades into GDM itself crashing.

Log sequence (journalctl -b -1, timestamps BST)

Right as driftwm's session ends and GDM starts its greeter on the same VT:

driftwm: WARN drm_atomic: driftwm::backend::udev: Failed to queue frame: DrmError(Access(AccessError { errmsg: "Page flip commit failed", dev: Some("/dev/dri/card1"), source: Os { code: 13, kind: PermissionDenied, message: "Permission denied" } }))

(repeats 3 times over the following second)

The greeter's own password conversation then breaks down — not a wrong password, the conversation itself fails:

gdm-password][8434]: pam_unix(gdm-password:auth): authentication failure; ... user=pulser
gdm-password][8879]: pam_unix(gdm-password:auth): conversation failed
gdm-password][8879]: pam_unix(gdm-password:auth): auth could not identify password for [pulser]
gdm-password][8879]: gkr-pam: no password is available for user

And GDM itself dies:

systemd[1]: gdm.service: Main process exited, code=exited, status=1/FAILURE
systemd[1]: gdm.service: Failed with result 'exit-code'.

gdm.service has Restart=always, but recovering from this required a full reboot in practice.

What I checked before filing

• main() returns via a normal Ok(()) at the end (not std::process::exit()), so Rust's destructors — including whatever Drop impl the smithay-provided LibSeatSession has — should run as part of normal shutdown. No std::process::exit() anywhere in the non-error shutdown path.
• No explicit DRM-master-release / session.close() call in src/backend/udev.rs — shutdown relies entirely on the LibSeatSession's own Drop behavior.

Given that, this might be a timing race (GDM's greeter trying to acquire DRM master a moment before driftwm's teardown actually completes) or something in smithay's libseat session handling rather than driftwm's own code — I didn't want to guess-and-check a fix live, since a bad attempt risks a broken login screen requiring a hard reboot to recover, so I'm filing this as an observation rather than a patch.

Environment

• Fedora/Nobara, GDM 49, driftwm 0.13.0 built from source, udev backend
• 3-monitor setup, one output (HDMI-A-1) rotated 90°
• GPU: /dev/dri/card1

Happy to help narrow this down further if there's a specific place in the shutdown path you'd like traced with RUST_LOG=debug.

[malbiruk]

Thanks for the detailed report — and for not guess-and-checking a fix, this is one where a bad attempt can leave you staring at a dead login screen.

I think your "timing race in smithay's session handling" instinct is right. The Access(... PermissionDenied ... "Page flip commit failed") is the tell: smithay short-circuits DRM ops with DeviceInactive once a session is paused, so an EACCES from an actual page-flip means the device's internal active flag was still true — i.e. our PauseSession handler (which drops DRM master) never ran before teardown. logind revoked our master for the greeter handoff, but we didn't process the session-disable in time. Because active stayed true, smithay's DrmDevice drop then fires a full ALLOW_MODESET restore of the pre-driftwm state right as the greeter is taking the device — the likely reason it can't get display access (the PAM/gkr errors are downstream of the greeter GUI never coming up).

To confirm before I touch anything, could you redo the logout with RUST_LOG=debug and check journalctl -b -1 for:

1. Does Session paused (VT switch away) appear at all during logout? (My bet: no.)
2. Any smithay Device still active, trying to restore previous state / Failed to restore previous state lines?
3. Once wedged, is anything still holding the node? sudo fuser -v /dev/dri/card1

Thanks again for the great writeup.