SUMMARY *** The kscreenlocker recovery advice doesn't make sense when there are not VTs. to switch back to the running session to press CTRL+ALT+F0 (since the logind VT number is 0 when there are none). And then on the bottom, it says "you can get back to this screen by pressing "CTRL+ALT+Fc2" where "c2" is the logind session *** STEPS TO REPRODUCE 1. Build a kernel without VTs 2. Start KDE Plasma 3. Lock the screen 4. Kill the screen locker somehow, with an SSH session or something OBSERVED RESULT 1. The messages are shown above, the second CTRL+ALT+Fx key that it tells the user to press will likely vary by the logind session number EXPECTED RESULT Honestly I am not sure what the solution is. CTRL+ALT+Fx bindings still work without VTs, but it's only if there is another session to switch to Most display manager's don't keep the greeter running, and some run the greeter as root, so the greeter isn't a logind session for the greeter. I almost wonder if logind would need to be amended to have a dbus command that starts a usermode terminal on its own Wayland session on the seat, with a login getty on i or something This is in a similar vein as https://github.com/systemd/systemd/issues/26313 ...although in this instance, kwin is usually able to respond to user key commands, (where I opened https://github.com/systemd/systemd/issues/26313 in the case where it's the display server that hangs solid) SOFTWARE/OS VERSIONS Linux/KDE Plasma: Kernel 6.1 KDE Plasma Version: 5.26.80 KDE Frameworks Version: 5.102.0 Qt Version: 5.15.8
I opened https://github.com/systemd/systemd/issues/26313 for systemd/logind My thinking is that, logind will have to listen on the keyboard for a key binding, like a long press and hold of CTRL+SHIFT+ESC or something and when that happens, emit a dbus signal that the display manager will start the greeter, or switch to the greeter session if it is running on the seat, and then the user will be able to log in with a separate session. Maybe a minimalistic one provided by kmscon, or combining cage and foot.
https://github.com/systemd/systemd/pull/29542 is out of draft and waiting further review, but right now if you hit Ctrl+Alt+Shift+Esc with that applied org.freedesktop.login1.Manager emits the SecureAttentionKey signal, with the seat object that it was originated from, to where a display manager can react to it, and show its greeter If this gets merged, it might allow users to log in and start a second session to run the command (although it will have to be a minimal one like Weston, or one that pairs cage/foot) It might be better than guessing the VT
https://github.com/systemd/systemd/pull/29542 is merged, which might be relevant to this This could allow new instructions to where they are to press Ctrl+Alt+Shift+Esc and then log in with a new session (would have to be like Weston or something because you can't have two systemd handled sessions) and then run the command with that ...that is once the patch is in in sddm
Now SDDM supports responding when systemd emits SecureAttentionKey after the user presses Ctrl+Alt+Shift+Esc GDM support is pending, as is LightDM (patches are yet to be reviewed) BUT this might be better advice to the user, press Ctrl+Alt+Shift+Esc, log in selecting a different session type, then run the loginctl command?
Please see https://bugs.kde.org/show_bug.cgi?id=473247#c7 I accidentally posted in the wrong tab