Bug 360489

Summary:	kscreenlocker suggests running "loginctl unlock-sessions" even though I don't use systemd
Product:	[Plasma] kscreenlocker	Reporter:	Alexander Potashev <aspotashev>
Component:	general	Assignee:	Plasma Bugs List <plasma-bugs>
Status:	RESOLVED INTENTIONAL
Severity:	normal	CC:	bhush94, dmitryy.demin, kde_bugs, mgraesslin, nick, pkozlov.vrn, simonandric5
Priority:	NOR
Version:	5.5.95
Target Milestone:	---
Platform:	Gentoo Packages
OS:	Linux
Latest Commit:		Version Fixed In:

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
\n
loginctl unlock-sessions\n
\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




kscreenlocker-5.5.95

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

OH SHI~~~

https://plus.google.com/u/0/+MartinGr%C3%A4%C3%9Flin/posts/Pw31EE21BXV

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:
Session1:
...
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.