Description of problem:
The function "switch user" in KDE doesn't work in F19.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Log into KDE with UserA
2. Click to the K-Menu and choose "switch user"
3. Click "New session"
After the described steps, the screen turns black with a cursor for 2 seconds, then I see only the F19 wallpaper for about 45 seconds. Then the screen is locked from UserA and I have to enter the password of UserA to return to it's desktop.
After clicking "New session", the login screen should appear and allows to login with a different account.
"Switch user" worked fine in F18.
Assuming you're using kdm to as login manager here (please do mention otherwise if that is not the case).
Where can I see, which login manager is used?
During the F19 installation I just choosed the KDE desktop group (instead the default Gnome). And nothing else was changed byside that.
this should give a hint: (run in a console or terminal):
$ systemctl status display-manager
Thanks for that hint. This is the output:
# systemctl status display-manager
kdm.service - The KDE login manager
Loaded: loaded (/usr/lib/systemd/system/kdm.service; enabled)
Active: active (running) since Fr 2013-06-21 17:22:16 CEST; 2h 28min ago
Main PID: 382 (kdm)
├─382 /usr/bin/kdm vt1
└─424 /usr/bin/X :0 vt1 -background none -nolisten tcp -auth /var/run/kdm/A:0-PMG02b
thanks for your report. I just tried install Fedora 19 TC6 from a netinstall iso while only checking KDE instead of GNOME desktop.
Switching users works fine, it just crashed KWin in the second session for some reason, which seems to be a different problem here.
Could you please write how your installation differs from mine?
this is, how I installed:
- Netinstall with ISO downloaded on 2013-06-17
- choosed KDE instead of Gnome desktop
- Installed only from Base. I unchecked automatic Updates during the installation, because it failed on the first try (maybe because I got a mirror, that hasn't had the F19 update directory).
- I created on user during setup
- After the Installation I "yum update" the whole system.
- Added a second user
I meanwhile saw, that on some less tries, the user switching works. But this is a very rare situation and I can't reproduce, when. Mostly the user switch fails.
And the installation was done on my real computer (no VM).
thanks for the information! Well, I can't reproduce the behavior on any of my systems (in comment #5 I was talking about a clean virtual machine where 4.10.4-5 KDE packages were installed from the repositories... there isn't much of a difference in the update that would cause this), virtual or physical.
If you happen to trigger the problem again, could you please post your journalctl output from the time when it happened?
Created attachment 765260 [details]
After about 1h of logon/logoff/switch user and reboots I found out the following:
The switch user problem seems to appear, when a user log in and start "Konsole". In many (not all) times, I see the task already in the task bar, but the window doesn't appear for about 20 seconds (other programs like FireFox I directly open when I click them). When the Konsole window comes up then, and I try to switch user, the described problem exists.
In some situations, Konsole directly opens after clicking the pinned taskbar icon or when starting from the K-Menu. The the switch user works in that situations. Also it works, if I just log into KDE, open nothing and directly try to switch the user.
Find attached the journalctl output. It contains the startup, login as user, open a Konsole window (at a time, when it took that long time to appear) and after it opened, I tried to switch user in KDE, what failed.
Please let me know if I can provide further details, logs, etc.
> but the window doesn't appear for about 20 seconds
This sounds like kded4 is hanging. Workaround: killall -9 kded4, then restart kded4.
I'm pretty sure this issue isn't entirely related to the user switching code in kde-workspace, yet I'm unable to reproduce the bug myself on any of my computers with Fedora 19.
Did you notice any other unusual behavior of your desktop? High resource (CPU, memory...) usage of some process? Kevin suggested kded4 could be hanging - did restarting it help, please?
Also, if you didn't solve it yet, could you please provide your ~/.xsession-errors output?
Created attachment 768951 [details]
Hello Kevin, hello Martin,
- login with my account
- open konsole (took some seconds on the first start, what indicates, that switch user won't work if I try)
- try to switch user - it fails and hangs, as described
- returning to my account by unlocking the screen
- kill kded4 as described
- checked with ps that it's not running any more (it wasn't)
- start kded4 again
- try switch user again - fails again.
The attached .xsession-errors file contain the abobe steps.
This time I need 8 reboots and tries, before I could not switch user. And the steps I did where always the same. But I can say that when konsole needs several seconds to appear on it's first start after login, then the switch user also doesn't work.
This message is a notice that Fedora 19 is now at end of life. Fedora
has stopped maintaining and issuing updates for Fedora 19. It is
Fedora's policy to close all bug reports from releases that are no
longer maintained. Approximately 4 (four) weeks from now this bug will
be closed as EOL if it remains open with a Fedora 'version' of '19'.
Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version.
Thank you for reporting this issue and we are sorry that we were not
able to fix it before Fedora 19 is end of life. If you would still like
to see this bug fixed and are able to reproduce it against a later version
of Fedora, you are encouraged change the 'version' to a later Fedora
version prior this bug is closed as described in the policy above.
Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.
Fedora 19 changed to end-of-life (EOL) status on 2015-01-06. Fedora 19 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.
If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
Thank you for reporting this bug and we are sorry it could not be fixed.