[gentoo-user] Unlocking Plasma desktop in Gentoo without systemd

[Mick]

I started a plasma session and after some period of input inactivity I noticed
the screen blanked out. Later on I moved the mouse and to my surprise I
obtained this message:
*********************
"The screen locker is broken and unlocking is not possible anymore.
In order to unlock switch to a virtual terminal (e.g. Ctrl+Alt+F2),
log in and execute the command:

loginctl unlock-sessions

Afterwards switch back to the running session (Ctrl+Alt+F7)."
*********************

Given this is a non-systemd Gentoo installation and I intend to keep it this
way as long as reasonably practicable, what should I instruct the user to do
to recover their current plasma session?

If this is a default Gentoo installation with openrc, why does a default
plasma desktop screenlocker comes up with this nonsense?

--
Regards,
Mick

[Stroller]

> On 11 Sep 2017, at 18:49, Mick <michael...@gmail.com> wrote:
>
> …

> "The screen locker is broken and unlocking is not possible anymore.
> In order to unlock switch to a virtual terminal (e.g. Ctrl+Alt+F2),
> log in and execute the command:
>
> loginctl unlock-sessions
>

> ...

>
> If this is a default Gentoo installation with openrc, why does a default
> plasma desktop screenlocker comes up with this nonsense?

Is it possible some of your KDE components were emerged with USE="systemd"?

Try something like `emerge -pN world`?

Stroller.

[Jigme Datse Yli-RAsku]

I had a similar (if not identical problem). This solution is a
"difficult" solution, the reason I experienced this (if I understand)
was that I was running KDE at the same time I was updating KDE. I can't
remember if I simply rebooted, or if all it took was logging out, and
logging back in. Even if I had rebooted, the *most* that should be
required is restarting X, which if you are running XDM may require
restarting XDM, or as stated, simply logging out and logging back in
(but that might not be possible from KDE running in this broken mode).
It should happen relatively infrequently.

If you are doing unattended updates, you are likely to run into this
kind of problem from time to time. I do not recommend it except for
"security" updates, which I don't believe there is an automated process
in Gentoo to do. Ie. I don't believe Portage flags updates as
"security" updates in any way, so a single command of "emerge --update
--security-only @word" (to my knowledge) isn't really a possibility.

Though, also, I haven't been following recent discussions that closely,
and I only recently returned to Gentoo after about 10 years away.

[Daniel Frey]

On 09/11/2017 10:49 AM, Mick wrote:

> I started a plasma session and after some period of input inactivity I noticed
> the screen blanked out. Later on I moved the mouse and to my surprise I
> obtained this message:
> *********************
> "The screen locker is broken and unlocking is not possible anymore.
> In order to unlock switch to a virtual terminal (e.g. Ctrl+Alt+F2),
> log in and execute the command:
>
> loginctl unlock-sessions
>
> Afterwards switch back to the running session (Ctrl+Alt+F7)."
> *********************
>
> Given this is a non-systemd Gentoo installation and I intend to keep it this
> way as long as reasonably practicable, what should I instruct the user to do
> to recover their current plasma session?

Are you updating KDE? I always run into this issue when updating KDE, so
I now turn off the screen lock before I commence updating.

>
> If this is a default Gentoo installation with openrc, why does a default
> plasma desktop screenlocker comes up with this nonsense?
>

Because KDE expects people to use systemd, a bug was raised regarding
this issue, and the developers basically said you're on your own
(RESOLVED: WONTFIX):

https://bugs.kde.org/show_bug.cgi?id=360489

According to a comment in the bug, you can try to figure out which
session it is (ck-list-sessions) and look for the X11 display property
set. This will not work (or could be difficult) if you have several
users using KDE at the same time and can't tell the sessions apart.

Once you figure that out, remember the session name and:

# su -c 'dbus-send --system --print-reply \
--dest="org.freedesktop.ConsoleKit" \
/org/freedesktop/ConsoleKit/<session name> \
org.freedesktop.ConsoleKit.Session.Unlock'

This worked on my laptop running openrc. I now just disable the locker
before doing updates.

Dan

[Mick]

Thanks Stroller, but no, this PC never had any systemd component, on purpose:

# emerge -pN world

These are the packages that would be merged, in order:

Calculating dependencies... done!


I had disabled USE flag 'systemd' in make.conf as soon as this flag was
established:

$ euse -I systemd
global use flags (searching: systemd)
************************************************************

local use flags (searching: systemd)
************************************************************
[- c ] systemd (dev-qt/qtcore):
Enable native journald logging support

[- c ] systemd (media-sound/pulseaudio):
Build with sys-apps/systemd support to replace standalone ConsoleKit.

[- c ] systemd (sys-apps/accountsservice):
Use sys-apps/systemd instead of sys-auth/consolekit for session tracking

[- c ] systemd (sys-apps/busybox):
Support systemd

[- c ] systemd (sys-apps/dbus):
Build with sys-apps/systemd at_console support

[- c ] systemd (sys-auth/pambase):
Use pam_systemd module to register user sessions in the systemd control group
hierarchy.

[- c ] systemd (sys-auth/polkit):
Use sys-apps/systemd instead of sys-auth/consolekit for session tracking

[- c ] systemd (sys-fs/udisks):
Support sys-apps/systemd's logind

The interesting thing is I never enabled screen locking, so plasma ought to be
running with default settings. If such a setting causes the session to become
inaccessible it should have been disabled by default. There may have been a
warning about it in the past, but I can't recall it.

The funny thing was the user thought her machine was being hacked! o_O

I tried to pacify her by explaining that without systemd stack the attack
surface should be smaller. ;-p
--
Regards,
Mick

[Mick]

On Monday, 11 September 2017 19:27:02 BST Jigme Datse Yli-RAsku wrote:
> I had a similar (if not identical problem). This solution is a
> "difficult" solution, the reason I experienced this (if I understand)
> was that I was running KDE at the same time I was updating KDE.

No the user started a Plasma session after booting up the PC and while no
updates were being performed.

> I can't
> remember if I simply rebooted, or if all it took was logging out, and
> logging back in. Even if I had rebooted, the *most* that should be
> required is restarting X, which if you are running XDM may require
> restarting XDM, or as stated, simply logging out and logging back in
> (but that might not be possible from KDE running in this broken mode).
> It should happen relatively infrequently.

I can login and restart xdm, but I fear the user may lose some the work being
performed at the time. I may end up doing this, but not if there is a way to
recover the session. Strangely, I can't see any relevant screenlock process I
could stop from the console. :-(
--
Regards,
Mick

[Dan Johansson]

Try this:

# Get Session-ID
sesid=$(ck-list-sessions | egrep "(Session[0-9]:|x11-display = ':0')" |
grep -B 2 "x11-display = ':0'" | grep "Session" | cut -d":" -f1)

# Unlock
sudo dbus-send --system --print-reply
--dest="org.freedesktop.ConsoleKit" /org/freedesktop/ConsoleKit/${sesid}
org.freedesktop.ConsoleKit.Session.Unlock


--
Dan Johansson
***************************************************
This message is printed on 100% recycled electrons!
***************************************************

[Mick]

Thank you All, the suggestion to unlock the sessionID worked!

So, KDE is now becoming good as Gnome in becoming entwined with systemd. I
can see myself ending up in working on VTs only soon! ;-p

--
Regards,
Mick

[Michael Palimaka]

On 09/12/2017 05:04 AM, Daniel Frey wrote:
> According to a comment in the bug, you can try to figure out which
> session it is (ck-list-sessions) and look for the X11 display property
> set. This will not work (or could be difficult) if you have several
> users using KDE at the same time and can't tell the sessions apart.
>
> Once you figure that out, remember the session name and:
>
> # su -c 'dbus-send --system --print-reply \
> --dest="org.freedesktop.ConsoleKit" \
> /org/freedesktop/ConsoleKit/<session name> \
> org.freedesktop.ConsoleKit.Session.Unlock'
>

If there a nice way to wrap this up in a script I'd be interesting in
shipping this for non-logind systems.

Another option is sys-auth/elogind, which provides the logind interface
and tools (like loginctl) for non-systemd systems. This is what I've
been testing with OpenRC for some time.

I read that ConsoleKit is also supporting the logind dbus interface now.
This would in theory make it easy to create a tool to unlock the
session, but I haven't had a chance to test it yet.

[Mick]

I think if Plasma shipped with screenlock unset as a default this problem
would not exist for non-systemd set ups. I disabled Plasma's screenlock and
after after some time of inactivity eventually DPMS kicks in and the monitors
go into power saving mode. This negates for needing special scripts elogind
or anything else KDE/Plasma never needed before now.

Nevertheless, the suggestions for using dbus-send were useful for getting me
out of a hole. Thanks again! :-)
--
Regards,
Mick

[J. Roeleveld]

On Tuesday, September 12, 2017 2:13:32 PM CEST Michael Palimaka wrote:
> On 09/12/2017 05:04 AM, Daniel Frey wrote:
> > According to a comment in the bug, you can try to figure out which
> > session it is (ck-list-sessions) and look for the X11 display property
> > set. This will not work (or could be difficult) if you have several
> > users using KDE at the same time and can't tell the sessions apart.
> >
> > Once you figure that out, remember the session name and:
> >
> > # su -c 'dbus-send --system --print-reply \
> > --dest="org.freedesktop.ConsoleKit" \
> >
> > /org/freedesktop/ConsoleKit/<session name> \
> >
> > org.freedesktop.ConsoleKit.Session.Unlock'
>
> If there a nice way to wrap this up in a script I'd be interesting in
> shipping this for non-logind systems.

There is:
joost@eve ~ $ cat /usr/local/bin/unlock-screens.sh
ck-list-sessions | grep Session | sed 's/\(.*\):/dbus-send --system --print-
reply --dest\=\"org.freedesktop.ConsoleKit\" \/org\/freedesktop\/ConsoleKit\/
\1 org.freedesktop.ConsoleKit.Session.Unlock/' | sh

joost@eve ~ $ cat /usr/local/bin/lock-screens.sh
ck-list-sessions | grep Session | sed 's/\(.*\):/dbus-send --system --print-
reply --dest\=\"org.freedesktop.ConsoleKit\" \/org\/freedesktop\/ConsoleKit\/
\1 org.freedesktop.ConsoleKit.Session.Lock/' | sh


I build these when I encountered this same issue nearly a year ago. I run them
as "root" and they will (un)lock ALL X-sessions.

> Another option is sys-auth/elogind, which provides the logind interface
> and tools (like loginctl) for non-systemd systems. This is what I've
> been testing with OpenRC for some time.

If it works better, I have no issue with it being pulled in.

> I read that ConsoleKit is also supporting the logind dbus interface now.
> This would in theory make it easy to create a tool to unlock the
> session, but I haven't had a chance to test it yet.

Better solutions are always welcome.

--
Joost

[Daniel Frey]

Well, I forgot to disable my screen locker during an update and got bit
by this again. It's a pain typing it manually (especially when you run a
monitor in portrait mode.)

I had some time and put together a general-purpose bash script. A note
of warning, I'm not an expert at bash by any means, but I was able to
test this several ways as I haven't restarted my computer yet.

I'll attach it if someone else wants to try it out. It's simply called
ck-unlock-session.

Dan