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

[Mick]

On Monday, 11 September 2017 20:27:02 BST Dan Johansson wrote:
> On 11.09.2017 21:04, Mick wrote:
> > 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.  :-(
> 
> 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

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

signature.asc
Description: This is a digitally signed message part.

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

[Dan Johansson]

On 11.09.2017 21:04, Mick wrote:
> 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.  :-(
> 

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!
***

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

[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

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

[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/ \
org.freedesktop.ConsoleKit.Session.Unlock'

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


Dan

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

[Mick]

On Monday, 11 September 2017 19:18:30 BST Stroller wrote:
> > On 11 Sep 2017, at 18:49, Mick  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.

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

signature.asc
Description: This is a digitally signed message part.

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

[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.

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?
> 
> If this is a default Gentoo installation with openrc, why does a default 
> plasma desktop screenlocker comes up with this nonsense?
> 



signature.asc
Description: OpenPGP digital signature

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

[Stroller]

> On 11 Sep 2017, at 18:49, Mick  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.

[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

signature.asc
Description: This is a digitally signed message part.