Often when I log in to my KDE session, it comes up in a broken state: Global shortcuts do not work, encrypted wireless connections can not be established, I can not log out or shut down the PC. Then I have to hit Ctrl-Alt-Backspace and log in again to get everything working. This only happens the very first time I log in after startup - the re-login always succeeded. I' estimate that I have this issue every 3rd time I boot my machine. Reproducible: Sometimes Steps to Reproduce: Not reproducible, unfortunately: 1. Start PC 2. Log in to KDE Actual Results: KDE is broken: Global shortcuts do not work (neither those defined in KMenuEdit, nor things like Win-R to open KRunner or Win-L to lock the screen), logging in to a wireless network with encryption does not work (it asks for the KWaller password, but the login to the network does not proceed), and logging out does not work either. Expected Results: KDE should come up properly. Interesting enough, wireless networks which do not require a password work fine. Also, hitting "Run Command..." in the desktop context menu works. I suspect some part of kded, or some inter-process communication, is not starting properly, maybe due to a race condition - but I have no idea how to even find out what's actually broken. Any help for debugging is appreciated. I am using KDE 4.9.3 which I compiled myself from sources.
Are you using systemd? It is possible that certain system services (e.g. D-Bus), are started asynchronously, and not yet available when KDE starts.
> I suspect some part of kded, or some inter-process communication, is not starting properly Maybe compare the process list, once for the case where it works, and the other time when it does not work.
(In reply to comment #1) > Are you using systemd? It is possible that certain system services (e.g. > D-Bus), are started asynchronously, and not yet available when KDE starts. No, I am using Debian testing with the (default) sysv init system. (In reply to comment #2) > Maybe compare the process list, once for the case where it works, and the > other time when it does not work. I will try that next time it happens, thanks.
Interesting enough, the broken session has some processes *more* than a working one: kmix, krunner, kwalletmanager are running twice. Other than that, everything looks the same. kactivitymanagerd is not stopped by Ctrl-Alt-Backspace, instead it still runs in background and blocks shutdown (does not react to TERM). I assume this is a different bug?
Ctrl+Alt+Backspace is not a recommended way to terminate a session. Do the processes disappear, when you log out via the session manager?
(In reply to comment #5) > Ctrl+Alt+Backspace is not a recommended way to terminate a session. Do the > processes disappear, when you log out via the session manager? I can not log out using the K-Menu when the session is in this broken state. I am not sure whether the logout confirmation dialogue appears, but KDE just refuses to terminate. It's not like I like killing all processes with Ctrl-Alt-Backspace ;-) Not sure what you mean by "using the session-manager" - is there a way to talk with ksmserver directly?
> I can not log out using the K-Menu when the session is in this broken state. If I understand you correctly, you got into this state because you did not log out cleanly. To check if this is the case, reboot the machine, log out via KRunner or the Kickoff menu, then check in Ctrl+Alt+F1 console, if there are any KDE processes remaining.
(In reply to comment #7) > If I understand you correctly, you got into this state because you did not > log out cleanly. No, the broken state happens approximately every 3rd time I boot the machine and log in. Then I do Ctrl-Alt-Backspace as it is the only way to get out of the session, log in again, and it's all working. I recently noticed that Konsole is also broken in a weird way: I can no longer select text, it the whole konsole process locks up if I try to. On another note, I am using lightdm as my display manager - not that this should make any difference.
Konsole blocking when selecting text is bug 306338 (which needs more people to check, which kded module is responsible). Can you be more specific what "broken state" you get after a fresh boot? Does Alt+F2 or Ctrl+Alt+F1 still work?
> I am using KDE 4.9.3 which I compiled myself from sources. This might be a problem, if you do not install into system directories. Does the same broken state appear, if you use KDE from distribution packages?
(In reply to comment #9) > Can you be more specific what "broken state" you get after a fresh boot? > Does Alt+F2 or Ctrl+Alt+F1 still work? As I wrote in the initial report: Global shortcuts do not work (neither those defined in KMenuEdit, nor things like Win-R to open KRunner or Win-L to lock the screen), logging in to a wireless network with encryption does not work (it asks for the KWaller password, but the login to the network does not proceed), and logging out does not work either. (In reply to comment #10) > This might be a problem, if you do not install into system directories. Does > the same broken state appear, if you use KDE from distribution packages? My distribution does not provide KDE 4.9 yet, which is why I compiled from sources. However, KDE is installed into the system directories. Even PolicyKit works (didn't test that in the broken state though), which usually was the most complicated thing to get running in my self-compiled KDE installations.
I forgot to mentioned: Win+R is my local configuration for what's usual Alt+F2. Ctr+Alt+F<nr> still work - but these are not handled by KDE, of course. Hence my conclusion (this is pure guessing!) that the daemon providing global shortcuts in KDE is broken. kglobalaccel is running though in the broken state (not sure if that's the right one).
I managed to catch a backtrace twice of kded4 when the session is in this broken state. In both cases, the main thread backtrace ends with: Thread 1 (Thread 0x7fb13078a760 (LWP 3461)): #0 0x00007fb12d435f01 in ppoll (fds=<optimized out>, nfds=<optimized out>, timeout=<optimized out>, sigmask=<optimized out>) at ../sysdeps/unix/sysv/linux/ppoll.c:57 #1 0x00007fb11de85437 in pa_mainloop_poll () from /usr/lib/x86_64-linux-gnu/libpulse.so.0 #2 0x00007fb11de859f9 in pa_mainloop_iterate () from /usr/lib/x86_64-linux-gnu/libpulse.so.0 #3 0x00007fb105de6ecf in ?? () from /usr/lib/kde4/kded_kmixd.so #4 0x00007fb105de74c4 in ?? () from /usr/lib/kde4/kded_kmixd.so #5 0x00007fb105df37df in ?? () from /usr/lib/kde4/kded_kmixd.so #6 0x00007fb105dfabe6 in ?? () from /usr/lib/kde4/kded_kmixd.so #7 0x00007fb105dfb87f in ?? () from /usr/lib/kde4/kded_kmixd.so #8 0x00007fb105df12ab in ?? () from /usr/lib/kde4/kded_kmixd.so #9 0x00007fb105df1e57 in ?? () from /usr/lib/kde4/kded_kmixd.so #10 0x00007fb12f9285a5 in KPluginFactory::create (this=0x2773590, iface=0x7fb12f97ee00 "KDEDModule", parentWidget=0x0, parent=0x2265460, args=..., keyword=...) at /home/r/src/kde/kde-stable/kde-sc/kdelibs/kdecore/util/kpluginfactory.cpp:203 I will recompile kmix with debug information and then catch a full backtrace to attach, but at least we know which kded module is (probably) responsible.
Created attachment 75703 [details] Backtrace of kded being stalled I managed to catch another backtrace, this time with KDE 4.9.4 and the kmix debug symbols. The full backtrace of all threads is attached, the interesting part is: #0 0x00007fce07a54f01 in ppoll (fds=<optimized out>, nfds=<optimized out>, timeout=<optimized out>, sigmask=<optimized out>) at ../sysdeps/unix/sysv/linux/ppoll.c:57 #1 0x00007fcdf84a4437 in pa_mainloop_poll () from /usr/lib/x86_64-linux-gnu/libpulse.so.0 #2 0x00007fcdf84a49f9 in pa_mainloop_iterate () from /usr/lib/x86_64-linux-gnu/libpulse.so.0 #3 0x00007fcde53a1ecf in Mixer_PULSE::Mixer_PULSE (this=0x225db40, mixer=<optimized out>, devnum=<optimized out>) at /home/r/src/kde/kde-stable/kde-sc/kmix/backends/mixer_pulse.cpp:935 #4 0x00007fcde53a24c4 in PULSE_getMixer (mixer=0x226a6e0, devnum=0) at /home/r/src/kde/kde-stable/kde-sc/kmix/backends/mixer_pulse.cpp:859 #5 0x00007fcde53ae7df in Mixer::Mixer (this=0x226a6e0, ref_driverName=..., device=0) at /home/r/src/kde/kde-stable/kde-sc/kmix/core/mixer.cpp:78 #6 0x00007fcde53b5be6 in MixerToolBox::initMixerInternal (this=0x0, this@entry=0x21a4480, multiDriverMode=multiDriverMode@entry=false, backendList=..., ref_hwInfoString=...) at /home/r/src/kde/kde-stable/kde-sc/kmix/core/mixertoolbox.cpp:146 #7 0x00007fcde53b687f in MixerToolBox::initMixer (this=0x21a4480, multiDriverMode=false, backendList=..., ref_hwInfoString=...) at /home/r/src/kde/kde-stable/kde-sc/kmix/core/mixertoolbox.cpp:78
It is inside pa_mainloop. Changing to Component Pulseudio.
Experiencing the same here with 4.10 but I never ran into this with 4.9. Though it is hard to tell whether there is any correlation with 4.10 since I did the update together with the switch to Fedora 18. Fortunately updating to pulseaudio 3 fixed the issue for me, but it might be as well just masquerading the race condition.
I have a similar issue with KDE 4.10.1: Sometimes after KDM logged me in automatically and I unlocked the screen, KDE is in an unusable state - I have to log out and log in again to get it to work. Examples of symptoms are: Klipper is not started and KMix is not working. It appears as if all programs have communication problems with each other.
I wonder whether it is related to PulseAudio. Please try KMix without PulseAudio: # Disable PulseAudio in KMix: killall kmix; sleep 2; kwriteconfig -file kmixrc -group Global -key Backends -type string ALSA sleep 1 ; kmix Please try and please report back. # Back to default behavior: killall kmix; sleep 2; kwriteconfig -file kmixrc -group Global -key Backends -type string "" ; sleep 1 ; kmix
I long stopped using kmix due to this bug and a few other issues with pulseaudio, so unfortunately I cannot help debugging anymore. Judging from the backtrace (see above), I think this is related to pulseaudio, but that's just guessing.
Thanks for the feedback, Ralf. I am usually not using PulseAudio, but once in a while I do for testing purposes for a couple of weeks. As nobody can give feedback, I will close this ticket.
As nobody is around who can give feedback any more, I will close this bug. It might be PA related or not, it might be connected to the MPRIS2 hangs, or whatever. Dennis Schridde reported, upgrading PA helps, so I will close this as "WORKSFORME".