can't unlock KDE session, loginctl req. but this is openrc

[as.gentoo]

Hello, i just wanted to unlock my KDE session, but I get a black screen with white letters telling me: "The screen locker is currently disturbed and the session can not be unlocked. To unlock it please switch to the console and execute 'loginctl unlock-sessions' you can then change back using ALT+CTRL+F7 to your running session." (translated from german)
This is an openrc-system, hence there is no loginctl.
I think that this happened during a system (@world) update.

What can I do do have my session unlocked?
Thanks in advance.

PS: I didn't see anything suspicious in /var/log/everything/current neither dmesg.

[asturm]

Have you already performed a re-login after upgrading world? If it contained Qt/Frameworks updates, this can break your running session.

[as.gentoo]

What kind of re-login? Into X or the system itself? I can not re-login to KDE as long I have that black screen, so I can not log out to login then.

Oh, there is SDDM accessible on CTRL+ALT+F8. Whatsoever logging in there results in a state that just looks like when the system booted (no apps started, KDE settings lost - both screens show the same now - all changes in documents lost, not yet sent emails lost...).

Is my session void now? If not, what can I do?

[as.gentoo]

Yes, tons of kde-framework packages was emerged.

If that is known to kill sessions maybe, you could temporarily deactivate screen locking. Please make "[x] turn off screen locking in case of emerge of potentially invalidating session emerge/updates" a switch that the user/admin can turn on and off.

Just out of curiousity, would loginctl have had "fixed" the issue?

[asturm]

Only for systemd users obviously.

[as.gentoo]

I know, but my session wouldn't be lost then? What does openrc provide then?


Edit:
Is there any other (kind of) package that could lead to the same problem? I could put that in my update script, that would demand a decision if to continue emerge or not.

[asturm]

It would certainly not be openrc's job, but needs an equivalent function within consolekit2...

[as.gentoo]

I see. Thanks so far!

I'm thinking of filing a feature request to the consolekit maintainers. Lets see how close they are tied to systemd.

[asturm]

Well, there might be one already that no one has looked up so far.

EDIT: An alternative logind implementation would be elogind, e.g.

[as.gentoo]

'eix elogind' outputs 'No matches found'. So I guess this would be part of an overlay then.

There was a specific package and command for the screen-locker process for KDE5. Which one is that? Maybe 'kill <pid>' would be enough to get rid of the lock?

[kensington]

I'm not aware of any way to kill the screenlocker when it's run into trouble on a non-systemd system.

EDIT: I did ask upstream about this again, and they don't care about non-systemd of course. They even refused any change to improve the message if loginctl is missing.

[as.gentoo]

The easiest solution is to use

[asturm]

consolekit2 does care about non-systemd users, since that's what it is existing for.

[julgo]

solution

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

[as.gentoo]

Thanks, that will really help next time.
You forgot to mention:

[kensington]

If we can integrate the dbus unlock into a simple script, I'd be happy to ship that and patch the wording of the emergency screen accordingly.

I'm also working on packaging of elogind - systemd's logind extracted into a standalone package. It's generally working for me OK with OpenRC so far, but I was not able to get the session locking/unlocking to work yet.

[genterminl]

I just ran into this, with kscreenlocker 5.7.5. I'll try the suggested approaches, but this just really dampens my enthusiasm for KDE.

[asturm]

Think of it as a security feature

So, there is a workaround, but for openrc users it is just a bit more inconvenient...

No.1 reason why this can happen is a Qt/Frameworks upgrade during an existing Plasma session, otherwise there seem to be some systems that have a bug with ~arch pam/fcaps due to kernel config or whatever, so not strictly related to Plasma, just being made visible there...

[genterminl]

I have to admit, my system has a whole host of other (but related) problems at the moment. Yes, I'm working on picking up the pieces. However, I'm pretty sure nothing related was upgraded at the time,. It was actually a test of startkde for a newly created user, so I think the lock may simply have been a legitimate timeout. In my case, they underlying issue is kwin_x11 crashes, but I've got plenty of other stuff to clean up before really digging into that. However, as you say, there are workarounds, even if they actually take some effort.

[asturm]

If only you did 'startkde' without launching a consolekit/dbus session for the user, then that will be the reason.

[genterminl]

How about "exec ck-launch-session startkde" as the last line of .xinitrc?

[gentooP4]

The arrogance of the devs is kinda outstanding here, but what's new when systemd is involved.
_________________
The United States has announced that it will deploy thoughts and prayers in the battle against online extremism.

If you voted for Trump or Brexit, you were likely influenced by the Cambridge Analytica propaganda machine.

[asturm]

Calm down. This is an extremely rare issue. Obviously non-systemd use-case is in need of a solution here, and a 10-lines CLI how-to on the lockscreen is not. Let's hope the standalone logind implementation will be it.

[Toomuch]

Thanks to julgo for the unlocking instructions. Ran into this today after updating nvidia-drivers and kholidays(!). Oh dear. I don't even need a screen locker for anything, just installed it to adjust the time before the display goes to sleep. Otherwise it would blank every 5 minutes

[asturm]

Well, kholidays has certiainly nothing to do with it. Make sure it does work now though, so that you do not run into it again, or else we can work towards fix your config.