Plasma5/KDE17 can't switch users

templarg · n00b Joined: 12 Jan 2018 Posts: 10

Hello Gentoo community,

I've met the following problem in some of the last KDE updates. I'm not able to Switch User. In already active session, when I click on this option, the session gets locked, the screen gets blank for a second, then back to the locked session but no new login screen appears. Same action on already locked session. This happen when I update KDE from 16 to 17. I've google this but I couldn't find any details how to solve this. The funny thing is that this works fine with the same KDE 17 in Fedora. Does anybody met such issue? Is the Switch User option disabled by default in Gentoo's KDE?

Thanks in advance.

The_S0urce · n00b Joined: 12 Jan 2018 Posts: 3

Hey templarg,

I have the exact same Problem after the last update-process.
I haven't found any solution yet. After logging out with the current user, I can start a new session without problems, only with an active running session, I'am not able to start a new one.

It's not an option issue, there have to be a process which is not working properly.

kensington · Posted: Sun Jan 14, 2018 6:59 am Post subject:

Are you using systemd, consolekit, elogind, and/or other?

The_S0urce · n00b Joined: 12 Jan 2018 Posts: 3

Hello kensington,

I'am using ConsoleKit.

templarg · n00b Joined: 12 Jan 2018 Posts: 10

Same here. I'm using only consolekit which is the default one for profile default/linux/amd64/17.1/desktop/plasma

kensington · Posted: Mon Jan 15, 2018 10:58 am Post subject:

Check out this wiki article.

Realistically though upstream only really supports logind these days. elogind is a good option for OpenRC users and will likely become our default in the future.

The_S0urce · n00b Joined: 12 Jan 2018 Posts: 3

Thanks kensington,

switched to elogind and it works now

NilPointer · n00b Joined: 02 Feb 2015 Posts: 41

Same here. I've been able to fix it by switching to elogind from ConsoleKit, following this article:

https://wiki.gentoo.org/wiki/Elogind

Huge thanks, kensington!

The_Great_Sephiroth · Posted: Tue Jan 16, 2018 2:57 pm Post subject:

This concerns me for several reasons. For one it seems we're starting to mimic systemd, which I do not care for at all. For another, what happens to things which rely on ConsoleKit?
_________________
Ever picture systemd as what runs "The Borg"?

asturm · Developer Joined: 05 Apr 2007 Posts: 8936

As far as I know there is no software that relies on consolekit exclusively. In most packages, consolekit support at this point is a neglected stepchild on life support.

Elogind will get us back into the game with full support, and it is even being developed by a Gentoo user.

l_arbalette · Posted: Sat Jan 20, 2018 11:52 am Post subject:

I had the same problem, solved it following https://wiki.gentoo.org/wiki/Elogind
but I tried to update my world a few days later...and consolekit was pushed again by portage, although I changed the USE flags in /etc/make.conf

I don't understand what I've missed to get definitively rid of consolekit ?

My profile is default/linux/amd64/17.0/desktop/plasma
here is my /etc/make.conf
here is the output of emerge --info .

and the output of emerge -ptuD world where you can see the following part :

asturm · Developer Joined: 05 Apr 2007 Posts: 8936

Also, networkmanager[elogind] is not set when it should be.

$ grep -R consolekit /etc/portage/package.use

l_arbalette · Posted: Sat Jan 20, 2018 12:46 pm Post subject:

That's the first thing I tried before asking for help....

sebB · l33t Joined: 02 Mar 2011 Posts: 806 Location: S.O. France

What does emerge -uDNvp @world say?

l_arbalette · Posted: Sun Jan 21, 2018 10:03 am Post subject:

Hi sebB
It gives the following
_________________
Proverbe chinois : L'homme qui pose une question peut sembler stupide, celui qui ne la pose pas le restera.
Abraham Maslow : Lorsque votre seul outil est un marteau, vous avez tendance à traiter tous les problèmes comme un clou.

sebB · l33t Joined: 02 Mar 2011 Posts: 806 Location: S.O. France

Are you sure you don't have any over entries in package.use?
Post

l_arbalette · Posted: Sun Jan 21, 2018 10:51 am Post subject:

Here it is :

templarg · n00b Joined: 12 Jan 2018 Posts: 10

Using elogind works for me and as far as I see only kde-plasma/powerdevil doesn't use elogind. But I'm still not sure what's the consolekit role in powerdevil. I'm just curious, if there is an issue switching the users because of consolekit, does anybody report that to the guys who develop this project? I didn't find any ConsoleKit tracking system. Their web page says they're actively working on systemd-logind. Does this mean in the close future openrc will be less maintained than systemd? Gentoo Handbook, all tarballs and most of the articles are OpenRC based and there is not much information about systemd but the Handbook says that Gnome 3.8 has already fully switched to systemd, so maybe it's a matter of time KDE to do the same. Does anybody knows what's the reason Gentoo team to actively support OpenRC instead of systemd?

l_arbalette · Posted: Sun Jan 21, 2018 4:47 pm Post subject:

I'm not sure, I'm not an expert : (kensington or asturm may correct it) but I would say that OpenRC / systemd for gentoo is a debate which is different from the logind / consolekit debate.
Even if logind is part of the systemd framework, we can choose (or at least we should be able to choose) the init system (openRC or systemd) independently from the tool managing the sessions (logind or consolekit)
elogind is precisely there to be able to choose logind mechanism without the whole systemd framework. And from what I understand from kensington's feedback, elogind will be supported in a near future (not necessarily questionning the choice of openRC). I understand that Gnome has been adapted to extensively use systemd ? but I would be surprised that we cannot choose a window manager like Gnome or KDE without beeing able to choose independently an init system...

That's why I'm surprised not to be able to get rid of consolekit, although I've following the wiki's steps on elogind...looks like a USE priorities issue, but I'm still struggling to find how to solve it...
_________________
Proverbe chinois : L'homme qui pose une question peut sembler stupide, celui qui ne la pose pas le restera.
Abraham Maslow : Lorsque votre seul outil est un marteau, vous avez tendance à traiter tous les problèmes comme un clou.

l_arbalette · Posted: Sun Jan 21, 2018 5:04 pm Post subject:

ok, problem solved : I re-emerged --one-shot networkmanager alone, since sebB made me discovered that doing this (with --pretend) was using the correct set of USE flags +elogind -consolekit
once this done, emerge -avuDN world was correct : consolekit is no longer appearing.
_________________
Proverbe chinois : L'homme qui pose une question peut sembler stupide, celui qui ne la pose pas le restera.
Abraham Maslow : Lorsque votre seul outil est un marteau, vous avez tendance à traiter tous les problèmes comme un clou.

xensystems · n00b Joined: 22 Jul 2012 Posts: 8

Appears to be a bug with kscreenlocker-5.11.5
Previous version 5.10.5.1 was working perfectly but it has been removed from portage.

Thanks for the hint with elogind, I've been struggling with this two days. :cry:

Maybe time has come to try moving to systemd...

xensystems · n00b Joined: 22 Jul 2012 Posts: 8

As per https://wiki.gentoo.org/wiki/KDE#No_display_manager
In case of CK I can start KDE manually without DM:

exec ck-launch-session dbus-launch --sh-syntax --exit-with-session startkde

how to do the same thing with elogind ? :roll:

nightkid · n00b Joined: 02 Oct 2013 Posts: 3

Switching from consolekit to elogind works; also note https://bugs.gentoo.org/647254 . Strangely enough, the socket path tried by kwallet-pam changed from /tmp/kwallet5_username.socket to /run/user/1000/kwallet5.socket, breaking kwallet-pam; the log looks perfectly normal to me except for the incorrect path:

Hu · Moderator Joined: 06 Mar 2007 Posts: 21633

Generally, storing objects in /tmp with a predictable or well-known name is a bad approach on multi-user systems. If another user wants to cause trouble, he can claim that name before the standard user of that name gets there. Depending on how much trouble he wants to cause and the quality of the programs meant to use that name, this can be a mere denial of service or it can be an effective attack. Storing the objects under /run/user/uid, where that path is guaranteed by the system to be owned by uid and not writable to anyone else, avoids these problems.

It is unfortunate that this migration broke something for you. Did you check whether a newer version of kwallet-pam requires a particular version of kwallet?

nightkid · n00b Joined: 02 Oct 2013 Posts: 3

I agree fully, but it's not like i decide where kwallet creates its socket - it was always in /tmp, the only change is that kwallet-pam tries connecting to a non-existent path now. I didn't touch any kwallet configuration. The curious thing is that the move to elogind didn't affect either package - they were not updated or reinstalled, but kwallet-pam started trying for a wrong path. I already had an up to date system, the move only replaced a handful of packages.

[IP-] [ ] kde-frameworks/kwallet-5.40.0:5/5.40
[IP-] [ ] kde-plasma/kwallet-pam-5.11.5:5
_________________
"It's the power cord", I say