'Switch user' not available in application launcher after upgrade to 20.10

Everything KDE built from source this morning with Qt 5.15.0 on top of openSUSE Tumbleweed.

Kickoff and Kicker are no longer displaying the "Switch User" functionality. However if I search for "Switch user" in KRunner, it displays an item called "New Session" which works as expected. It's just Kickoff and Kicker that don't have the functionality visible anymore.

Not reproducible with Plasma 5.19, just my built-from-source git master stuff.

Just re-appeared after a kernel update. :/

And now after another update it's gone missing again. Not sure what level of the stack is causing this. :(

I didn't have this issue on KDE Neon Unstable(Qt 5.14.2) and always had a look at the menu after updating and rebooting ;-).

I just reproduced this on a bare Neon User Edition install. :(

I cannot reproduce, but clearly we have some silly timing issue.

            m_valid = (KAuthorized::authorizeAction(QStringLiteral("start_new_session")) || KAuthorized::authorizeAction(QStringLiteral("switch_user")))
                && KDisplayManager().isSwitchable();
            break;

Eww, KDisplayManager has been deprecated since forever.

And this would have fixed it:

https://phabricator.kde.org/D20237

A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/137

*** Bug 425792 has been marked as a duplicate of this bug. ***

Git commit bb7b1226e65f533e21145b03047bfef604232323 by David Edmundson.
Committed on 30/09/2020 at 10:33.
Pushed by davidedmundson into branch 'master'.

[libkworkspace] Port from deprecated GetSessionByPID

This method calls doesn't seem to work anymore having been replaced by
the more intuitve virtual paths on the logind over a year ago.

Arguably that's still a bug upstream that GetSessionByPID no longer
works correctly, but we may as well port to the simpler path that avoids
so many layers of indirection.

Use of "/auto" does not exist on old distros so the legacy path is kept.

The paths used in this class were always wrong, which went unnoticed as
this is the first usage of them.

A +15 -0 components/tests/sessions.qml *
M +21 -13 libkworkspace/kdisplaymanager.cpp

The files marked with a * at the end have a non valid license. Please read: https://community.kde.org/Policies/Licensing_Policy and use the headers which are listed at that page.

https://invent.kde.org/plasma/plasma-workspace/commit/bb7b1226e65f533e21145b03047bfef604232323

Git commit 3acf8f30249ef256c2a915a12048f55da0568492 by David Edmundson.
Committed on 30/09/2020 at 10:48.
Pushed by davidedmundson into branch 'Plasma/5.20'.

[libkworkspace] Port from deprecated GetSessionByPID

This method calls doesn't seem to work anymore having been replaced by
the more intuitve virtual paths on the logind over a year ago.

Arguably that's still a bug upstream that GetSessionByPID no longer
works correctly, but we may as well port to the simpler path that avoids
so many layers of indirection.

Use of "/auto" does not exist on old distros so the legacy path is kept.

The paths used in this class were always wrong, which went unnoticed as
this is the first usage of them.

(cherry picked from commit bb7b1226e65f533e21145b03047bfef604232323)

A +15 -0 components/tests/sessions.qml *
M +21 -13 libkworkspace/kdisplaymanager.cpp

The files marked with a * at the end have a non valid license. Please read: https://community.kde.org/Policies/Licensing_Policy and use the headers which are listed at that page.

https://invent.kde.org/plasma/plasma-workspace/commit/3acf8f30249ef256c2a915a12048f55da0568492

The patch doesn't fix the issue on 5.19, according to downstream reports. On 5.20, this was already fixed by 05414ed58d43d87d907326636faac53ae2e7bd60

*** Bug 427673 has been marked as a duplicate of this bug. ***

Oh wth.

                QVariant prop = SDseat.property("CanMultiSession");
                if (prop.isValid())
                    return prop.toBool();

but there is no such property on
qdbus --system org.freedesktop.login1 /org/freedesktop/login1/seat/seat0

src/login/logind-seat-dbus.c: SD_BUS_PROPERTY("CanMultiSession", "b", property_get_const_true, 0, SD_BUS_VTABLE_PROPERTY_CONST|SD_BUS_VTABLE_HIDDEN),

So it does still exist, but it's hidden from introspection.
And always returns true anyway: 8f8cc84ba4612e74cd1e26898c6816e6e60fc4e9 which makes our check somewhat redundant!

I'm still confused by the reports in the duplicate saying it doesn't work.
It does here.

Can someone who still has an issue include output of:
 qdbus --system org.freedesktop.login1 /org/freedesktop/login1/seat/auto org.freedesktop.DBus.Properties.Get org.freedesktop.login1.Seat CanMultiSession

and reopen

(In reply to David Edmundson from comment #15)
> Can someone who still has an issue include output of:
>  qdbus --system org.freedesktop.login1 /org/freedesktop/login1/seat/auto
> org.freedesktop.DBus.Properties.Get org.freedesktop.login1.Seat
> CanMultiSession

qdbus --system org.freedesktop.login1 /org/freedesktop/login1/seat/auto org.freedesktop.DBus.Properties.Get org.freedesktop.login1.Seat CanMultiSession
Cannot find 'org.freedesktop.DBus.Properties.Get' in object /org/freedesktop/login1/seat/auto at org.freedesktop.login1

I'm using an older systemd/logind here (234) where "auto" doesn't exist.
It seems to work with "self" instead though:
qdbus --system org.freedesktop.login1 /org/freedesktop/login1/seat/self org.freedesktop.DBus.Properties.Get org.freedesktop.login1.Seat CanMultiSession
true

And to clarify: "Switch user" is available in the application menu here, but it's missing on the lock screen (because KDisplayManager::isSwitchable() returns false).
And it's not possible to switch to an existing session, only open a new one.

This is with Plasma 5.20.0. (and systemd 234 as mentioned)

I meanwhile added some debug output to KDisplayManager, and the problem apparently is this:
SDseat.property("CanMultiSession") = QVariant(Invalid)

(after the line "QVariant prop = SDseat.property("CanMultiSession");" in KDisplayManager::isSwitchable())

using systemd 245 I get:
achim@xxx:~$ qdbus --system org.freedesktop.login1 /org/freedesktop/login1/seat/auto org.freedesktop.DBus.Properties.Get org.freedesktop.login1.Seat CanMultiSession
true
achim@xxx:~$

I currently have no computer with systemd 246, but 246 causes the trouble.

Oh, interesting. So we have 3 options:

GetSessionByPid -> then get the seat
Seat/self
Seat/auto

GetSessionFromPid works in old systemd but broke in newer versions
self fails in some situations
auto is only available in new systemd

I assumed if auto didn't work I could just leave it on the old path... seemingly that is not the case.

(In reply to David Edmundson from comment #21)
> I assumed if auto didn't work I could just leave it on the old path...
> seemingly that is not the case.
Maybe the fallback doesn't work as intended?
I'll try to add more debug output to see what happens exactly on my system.

>I'll try to add more debug output to see what happens exactly on my system.

Thanks!

Super worst case, we can just return /self if /auto fails. It should work.

(In reply to David Edmundson from comment #15)
> src/login/logind-seat-dbus.c: SD_BUS_PROPERTY("CanMultiSession", "b",
> property_get_const_true, 0,
> SD_BUS_VTABLE_PROPERTY_CONST|SD_BUS_VTABLE_HIDDEN),
>
>
> So it does still exist, but it's hidden from introspection.
> And always returns true anyway: 8f8cc84ba4612e74cd1e26898c6816e6e60fc4e9
> which makes our check somewhat redundant!
>
> I'm still confused by the reports in the duplicate saying it doesn't work.
> It does here.
>
> Can someone who still has an issue include output of:
>  qdbus --system org.freedesktop.login1 /org/freedesktop/login1/seat/auto
> org.freedesktop.DBus.Properties.Get org.freedesktop.login1.Seat
> CanMultiSession
>
>
> and reopen

qdbus-qt5 --system org.freedesktop.login1 /org/freedesktop/login1/seat/auto org.freedesktop.DBus.Properties.Get org.freedesktop.login1.Seat CanMultiSession
true

zypper search -sxi systemd plasma5-session plasma-framework
Loading repository data...
Reading installed packages...

S | Name | Type | Version | Arch | Repository
---+------------------+---------+------------+--------+------------------------------
i+ | plasma-framework | package | 5.75.0-1.1 | x86_64 | openSUSE-Tumblweed (20201012)
i+ | plasma5-session | package | 5.19.5-3.1 | noarch | openSUSE-Tumblweed (20201012)
i+ | systemd | package | 246.6-1.1 | x86_64 | openSUSE-Tumblweed (20201012)

Switch user option isn't listed anywhere.

(In reply to Pavel from comment #24)
> i+ | plasma5-session | package | 5.19.5-3.1 | noarch | openSUSE-Tumblweed
> (20201012)
You should try with Plasma 5.20.0, for which this bug report was closed as fixed originally.
5.19.5 doesn't have the new code (https://invent.kde.org/plasma/plasma-workspace/commit/3acf8f30249ef256c2a915a12048f55da0568492) yet.

It should be in Tumbleweed soon.

(In reply to Wolfgang Bauer from comment #22)
> (In reply to David Edmundson from comment #21)
> > I assumed if auto didn't work I could just leave it on the old path...
> > seemingly that is not the case.
> Maybe the fallback doesn't work as intended?
> I'll try to add more debug output to see what happens exactly on my system.

Indeed, on my system (with systemd 234), it doesn't use the fallback with GetSessionByPID.
seat.isValid() is true in line#435, even though "auto" doesn't exist. So it enters the if() and returns true before calling GetSessionByPID.

If I disable that "if(seat.isValid() { return true; }" part (so the fallback is always used), the button is visible on the login screen now and clicking on it does show existing user sessions.
So the fallback code itself (with GetSessionByPID) does work.

Actually switching to an existing user session does apparently not work though, it just seems to hang on an empty screen (with the wallpaper and mouse pointer).
From the lock screen at least, it does seem to work when using the "user switch" applet.

I don't have more time for testing or investigating at the moment though. (and it might be an unrelated problem)

(In reply to Pavel from comment #24)
> (In reply to David Edmundson from comment #15)
> > src/login/logind-seat-dbus.c: SD_BUS_PROPERTY("CanMultiSession", "b",
> > property_get_const_true, 0,
> > SD_BUS_VTABLE_PROPERTY_CONST|SD_BUS_VTABLE_HIDDEN),
> >
> >
> > So it does still exist, but it's hidden from introspection.
> > And always returns true anyway: 8f8cc84ba4612e74cd1e26898c6816e6e60fc4e9
> > which makes our check somewhat redundant!
> >
> > I'm still confused by the reports in the duplicate saying it doesn't work.
> > It does here.
> >
> > Can someone who still has an issue include output of:
> >  qdbus --system org.freedesktop.login1 /org/freedesktop/login1/seat/auto
> > org.freedesktop.DBus.Properties.Get org.freedesktop.login1.Seat
> > CanMultiSession
> >
> >
> > and reopen
>
> qdbus-qt5 --system org.freedesktop.login1 /org/freedesktop/login1/seat/auto
> org.freedesktop.DBus.Properties.Get org.freedesktop.login1.Seat
> CanMultiSession
> true
>
> zypper search -sxi systemd plasma5-session plasma-framework
> Loading repository data...
> Reading installed packages...
>
> S | Name | Type | Version | Arch | Repository
> ---+------------------+---------+------------+--------+----------------------
> --------
> i+ | plasma-framework | package | 5.75.0-1.1 | x86_64 | openSUSE-Tumblweed
> (20201012)
> i+ | plasma5-session | package | 5.19.5-3.1 | noarch | openSUSE-Tumblweed
> (20201012)
> i+ | systemd | package | 246.6-1.1 | x86_64 | openSUSE-Tumblweed
> (20201012)
>
> Switch user option isn't listed anywhere.

:~> qdbus-qt5 --system org.freedesktop.login1 /org/freedesktop/login1/seat/auto org.freedesktop.DBus.Properties.Get org.freedesktop.login1.Seat CanMultiSession
true
:~> zypper search -sxi systemd plasma5-session plasma-framework
Loading repository data...
Reading installed packages...

S | Name | Type | Version | Arch | Repository
---+------------------+---------+--------------+--------+----------------------
i+ | plasma-framework | package | 5.75.0-306.1 | x86_64 | KDE-Frameworks
i+ | plasma5-session | package | 5.20.0-555.1 | noarch | KDE-Frameworks
i+ | systemd | package | 246.6-1.1 | x86_64 | Main Repository (OSS)

I have switch user function from the application menu which functions to take you to a new login screen showing list of users, and options; Switch to This Session, Start New Session, and Back. Choosing the Switch to This Session option results in session hang on an empty screen with the wallpaper and mouse pointer (same as described in comment 27). Start New Session, and Back both work as expected.

I do not have any options on the lock screen to Start New Session or Switch to This Session.

I can confirm this since 5.19.x and now on 5.20.1. This is definitely annoying, as it blocks secondary users from switching users when a lockscreen is present. Using Ctrl+Fx is definitely hacky and not a good way to switch users. I know that systemd introduced this, but please work this through...

Hope you are wrong am really hoping for a fix here. How is this not a severe bug? My wife is gonna kill me soon ;-)

(In reply to cyslider from comment #30)
> Hope you are wrong am really hoping for a fix here. How is this not a severe
> bug? My wife is gonna kill me soon ;-)

I completely agree - this should be marked SEVERE! The original bug only concerned missing functionality on the kicker menu. If limited to that, this would not prevent users from using the system. That kicker menu issue has been at least partially fixed.

However the current issue is regarding missing functionality on the lockscreen! This issue COMPLETELY DISABLES PROPER FUNCTION OF A MULTIUSER SYSTEM! Users CAN NOT LOGIN! That is not a normal bug importance! Apologies for CAPS :P

https://bugs.kde.org/show_bug.cgi?id=427673 was imho inappropriately marked "resolved duplicate" but that bug properly describes the current issue and its severity "Session management is totally broken - system does not work with multi-user parallel sessions - Critical."

The login screen regression is tracked with Bug 427777.

A workaround for using switching in a small environment.
It is possible to switch users via the command: "loginctl activate <session>"

I think I will try to create a shell script to switch to the correct user and stick it to the plasma desktop.

The only problem is that logind now keeps some processes alive and the list of active sessions becomes really long.

Here's the shell script to switch to a desktop of a particular user as a workaround.

https://github.com/jhaand/loginctl_switch

This will hopefully make life somewhat easier.

A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/407

A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/408

@Jelle Haandrikman: Thank you, but the main problem is that the user first has to get to a desktop to use this script. But he is stuck at the login screen of another user. So ctrl+alt+FX stays the only way currently it seems.

But it often happens that multiple sessions get created by accident this way and the profile starts to get damages at some point, increasing the frustration to the maximum

@<email address hidden> Indeed you need some extra workarounds. Disable the Screensavers and use "loginctl disable-linger" on those desktops. It works better if everything is kept clean. I now added the ".desktop" file to create a launcher on a desktop.

But this actually needs to get fixed.

Git commit 7c5f16c40e9bf27d6b1466c220b9eeaf800d4620 by David Edmundson, on behalf of Michail Vourlakos.
Committed on 01/11/2020 at 16:45.
Pushed by davidedmundson into branch 'master'.

Fix SystemEntries not updating correctly

The code is meant to add the entry if it's valid, then watch for
changes. Somehow we end up only monitoring if it was valid initially.
This doesn't make sense.

This means if the menu loads before the backend we don't update
correctly when it does load.
Related: bug 427779

M +2 -2 applets/kicker/plugin/systemmodel.cpp

https://invent.kde.org/plasma/plasma-workspace/commit/7c5f16c40e9bf27d6b1466c220b9eeaf800d4620

Git commit d3c0c394d4673198574ec6c5ab2f668e4a6621da by Nate Graham, on behalf of Michail Vourlakos.
Committed on 02/11/2020 at 15:33.
Pushed by ngraham into branch 'Plasma/5.20'.

Fix SystemEntries not updating correctly

The code is meant to add the entry if it's valid, then watch for
changes. Somehow we end up only monitoring if it was valid initially.
This doesn't make sense.

This means if the menu loads before the backend we don't update
correctly when it does load.
Related: bug 427779

(cherry picked from commit 7c5f16c40e9bf27d6b1466c220b9eeaf800d4620)

M +2 -2 applets/kicker/plugin/systemmodel.cpp

https://invent.kde.org/plasma/plasma-workspace/commit/d3c0c394d4673198574ec6c5ab2f668e4a6621da

Git commit f6269cadde64ac535092a74cb4fc493cc25014fe by David Edmundson.
Committed on 03/11/2020 at 11:23.
Pushed by davidedmundson into branch 'master'.

[libkworkspace] Fix if getCurrentSeat needs to fallback to old approach

The test for whether "/auto" is supported was bogus.

QDBusAbstractInterface::isValid effectively just confirms the service
exists and the path is a legally valid name, not that it has any
interfaces there.

This means the fallback path is not run appropriately.

M +1 -1 libkworkspace/kdisplaymanager.cpp

https://invent.kde.org/plasma/plasma-workspace/commit/f6269cadde64ac535092a74cb4fc493cc25014fe

Git commit b4ef966790c35cc3cf14f9953b8b83be0bc0f821 by David Edmundson.
Committed on 03/11/2020 at 11:44.
Pushed by davidedmundson into branch 'Plasma/5.20'.

[libkworkspace] Fix if getCurrentSeat needs to fallback to old approach

The test for whether "/auto" is supported was bogus.

QDBusAbstractInterface::isValid effectively just confirms the service
exists and the path is a legally valid name, not that it has any
interfaces there.

This means the fallback path is not run appropriately.

(cherry picked from commit f6269cadde64ac535092a74cb4fc493cc25014fe)

M +1 -1 libkworkspace/kdisplaymanager.cpp

https://invent.kde.org/plasma/plasma-workspace/commit/b4ef966790c35cc3cf14f9953b8b83be0bc0f821

Forgive my ignorance, but will this fix be backported to 5.18.x? Or will the fix only apply to 5.20.3?
Am currently on Kubuntu 20.04 with version 5.18.5.

Git commit c5fa3a15a444b0e7c9113b2dd0351e1cf7141d29 by Wolfgang Bauer.
Committed on 05/11/2020 at 20:29.
Pushed by wbauer into branch 'master'.

[lookandfeel] Fix switching to a different user session

Commit bcaf3886 removed the property `m` in UserDelegate.qml, but it is still used by
`userListCurrentModelData` in SessionManagementScreen.qml at least.

This broke switching to an existing session via the "Switch User" button on the lock screen or the
application launcher/menu, it just hung with an empty screen and this runtime error in the logs:
file:///usr/share/plasma/look-and-feel/org.kde.breeze.desktop/contents/lockscreen/LockScreenUi.qml:444: TypeError: Cannot read property 'vtNumber' of undefined

Adding it back makes switching work again (and gets rid of the runtime error).
FIXED-IN: 5.20.3

M +1 -0 lookandfeel/contents/components/UserDelegate.qml

https://invent.kde.org/plasma/plasma-workspace/commit/c5fa3a15a444b0e7c9113b2dd0351e1cf7141d29

Git commit 9a78614d4bbd9852a88bbecadc48a3f856e0214b by Wolfgang Bauer.
Committed on 05/11/2020 at 20:33.
Pushed by wbauer into branch 'Plasma/5.20'.

[lookandfeel] Fix switching to a different user session

Commit bcaf3886 removed the property `m` in UserDelegate.qml, but it is still used by
`userListCurrentModelData` in SessionManagementScreen.qml at least.

This broke switching to an existing session via the "Switch User" button on the lock screen or the
application launcher/menu, it just hung with an empty screen and this runtime error in the logs:
file:///usr/share/plasma/look-and-feel/org.kde.breeze.desktop/contents/lockscreen/LockScreenUi.qml:444: TypeError: Cannot read property 'vtNumber' of undefined

Adding it back makes switching work again (and gets rid of the runtime error).
FIXED-IN: 5.20.3

(cherry picked from commit c5fa3a15a444b0e7c9113b2dd0351e1cf7141d29)

M +1 -0 lookandfeel/contents/components/UserDelegate.qml

https://invent.kde.org/plasma/plasma-workspace/commit/9a78614d4bbd9852a88bbecadc48a3f856e0214b

(In reply to PGillespie from comment #43)
> Forgive my ignorance, but will this fix be backported to 5.18.x? Or will the
> fix only apply to 5.20.3?
> Am currently on Kubuntu 20.04 with version 5.18.5.
And what systemd version does Kubuntu 20.04 have?

According to my testing on the upcoming openSUSE Leap 15.3 (which has Plasma 5.18 and systemd 246), the only change needed to fix the problem there is the commit referenced in bug#427777, otherwise things seem to work well.

But it seems Ubuntu 20.04 has systemd 245 (can you confirm?). From what I understand that might have had a "bug" that broke the deprecated GetSessionByPID function (seems to be fixed again in 246), so probably the fix from comment#10 (https://invent.kde.org/plasma/plasma-workspace/commit/bb7b1226e65f533e21145b03047bfef604232323) would be needed as well (and https://invent.kde.org/plasma/plasma-workspace/commit/f6269cadde64ac535092a74cb4fc493cc25014fe to fix it again for older versions).

Maybe you should also contact the distribution about that.

This bug is still in Fedora 34:

Name : plasma-workspace
Version : 5.21.5
Release : 3.fc34

See also https://bugzilla.redhat.com/show_bug.cgi?id=1964485

In Fedora 34 there was a deliberate decision to remove it, because it does not work yet in the Plasma Wayland session, which was made the default session. Hopefully it will be back eventually. You would need to contact the Fedora KDE packagers for more information.

@Nate : is there a new issue for Wayland switch user functionality as this one is resolved?

I don't know, sorry.

Here's some sddm-related references on the topic at least,
https://bugs.kde.org/show_bug.cgi?id=435389
and
https://github.com/sddm/sddm/issues/1281