Bug 360489 - kscreenlocker suggests running "loginctl unlock-sessions" even though I don't use systemd
Summary: kscreenlocker suggests running "loginctl unlock-sessions" even though I don't...
Alias: None
Product: kscreenlocker
Classification: Plasma
Component: general (show other bugs)
Version: 5.5.95
Platform: Gentoo Packages Linux
: NOR normal
Target Milestone: ---
Assignee: Plasma Bugs List
Depends on:
Reported: 2016-03-13 19:14 UTC by Alexander Potashev
Modified: 2016-11-27 10:56 UTC (History)
7 users (show)

See Also:
Latest Commit:
Version Fixed In:


Note You need to log in before you can comment on or make changes to this bug.
Description Alexander Potashev 2016-03-13 19:14:42 UTC
When kscreenlocker_greet is unable to start (in my case incompatible Qt components were installed), it shows the following message:
The screen locker is broken and unlocking is not possible anymore.\n
In order to unlock switch to a virtual terminal (e.g. Ctrl+Alt+F2),\n
log in and execute the command:\n
loginctl unlock-sessions\n
Afterwards switch back to the running session (Ctrl+Alt+F%1).

But it is not helpful for me because I don't have systemd installed, thus I don't have the loginctl binary. This only creates confusion.

How do I unlock session without systemd?

Reproducible: Didn't try

Comment 1 Alexander Potashev 2016-03-13 19:22:47 UTC

Comment 2 Martin Flöser 2016-03-14 07:06:29 UTC
There is nothing wrong there. It's a fallback for the case that something is seriously broken. We improved that experience from black screen to something which works on 99 % of our users systems. There is no Plasma developer who doesn't use logind, so it's just not possible for us to support anything else. We expect the non-logind users to add code for this (which could also be a dummy loginctl binary which just works the same way). (Similar code was contributed to support consolekit in kscreenlocker).

From our side this is a clear wontfix or more a cantfix. Please do not expect us to go an extramile to support a corner case of the corner case.
Comment 3 Dmitry Demin 2016-04-07 20:32:23 UTC
If anybody needs it, I have found another solution to the problem, not involving using systemd.
First, we have to determine which session is X11 session. To accomplish that, run
# ck-list-sessions
in any virtual terminal (e.g. using Ctrl+Alt+F2).
One of sessions should contain x11-display property set - that session is possibly corresponding to a locked one:
x11-display = ':0'

Remember that session name ("Session1").
Now run the following command as root from the virtual terminal (below su is used to obtain root privileges)
# su -c 'dbus-send --system --print-reply --dest="org.freedesktop.ConsoleKit" /org/freedesktop/ConsoleKit/Session1 org.freedesktop.ConsoleKit.Session.Unlock' 
Where you should replace Session1 with your session name obtained at the previous step using ck-list-sessions.
After that you should be able to switch back to the running session (Ctrl+Alt+F%1).
Tested on Gentoo kde-plasma/kscreenlocker-5.6.2.
Comment 4 Martin Flöser 2016-04-08 05:45:02 UTC
Thanks Dmitry. That approach looks good. Unfortunately it's a little bit too complex to put on the emergency screen. If we had something as simple as consolekitctl unlock-sessions it would be doable to check whether logind or consolekit is used and show the correct command.
Comment 5 pkozlov 2016-11-27 10:56:49 UTC
Confirming - I have the same issue and it's really annoying - I can't unlock screen if I am currently updating kdelibs or qt or something...

And I don't use systemd, I use openrc.