Hello! Since upgrading to Kubuntu 13.10 i'm experiencing random freezes all around the kde world. This freezes never touches any non kde app, e.g. chrome, netbeans etc is working always. I think the problem lies within some shared module or lib, that locks up sometimes, as the locks are not always happens the same way and affects the same way the gui. At times, the whole plasma-desktop locks up, so no response from the taskbar, neither alt-f2 neither trigger desktop-grid via screen edge. But at times only one app freezes (like krusader or systemsettings) and others are not touched. What have caused lockups so far? (The following list means, it happened during this events, but doesn't mean, that it always locks up when i do them) * Opening new tab in yakuake * Opening systemsettings * Renaming a file in krusader (it freezed before move, and before the gui textbox would become a normal line again) * Messing around plasma widgets * Just opening k-menu (i use the classic one) * Entering a folder from krusader I would like to help you in everything to debug this out, you can contact me directly via email or some im (eg skype) if you want, i would really appreciate that. I've tried to mess around with plasma-desktop and strace, but i'm not an expert in debugging c/c++ apps, but what i have found two things: * Many times it select()-s on something which is never doing anything seemingly while the gui is frozen * Just a few minutes ago i've read a trick about disabling gestures in #325265, and systemsettings is just decided to not let me do that (freezed after every event), so i straced that too, and it was stuck at poll/recvmsg. In detail: 1st case: meta@x220:~$ ps aux | grep plasma meta 6272 3.1 2.5 3355504 204080 ? Sl 23:12 1:00 /usr/bin/plasma-desktop meta 7457 0.0 0.1 190800 10676 ? S 23:41 0:00 kdeinit4: kio_desktop [kdeinit] desktop local:/tmp/ksocket-meta/klauncherhX7452.slave-socket local:/tmp/ksocket-meta/plasma-desktopDr6272.slave-socket meta 7653 0.0 0.0 10940 980 pts/10 S+ 23:44 0:00 grep --color=auto plasma meta@x220:~$ sudo strace -f 6272 [sudo] password for meta: strace: Can't stat '6272': No such file or directory meta@x220:~$ sudo strace -fp 6272 Process 6272 attached with 5 threads [pid 7204] select(5, [4], NULL, NULL, NULL <unfinished ...> [pid 6279] restart_syscall(<... resuming interrupted call ...> <unfinished ...> [pid 6278] restart_syscall(<... resuming interrupted call ...> <unfinished ...> [pid 6275] futex(0x7f8eb60c8fd4, FUTEX_WAIT_PRIVATE, 1, NULL <unfinished ...> [pid 6272] select(30, [29], [], NULL, NULL And this is where it was for 15minutes, of course being frozen the whole time. 2st case with systemsettings: [pid 11028] sendmsg(5, 0x7fff04693a50, MSG_NOSIGNAL) = 161 [pid 11028] poll([?] 0x7fff04693b30, 1, 25000) = 1 [pid 11028] recvmsg(5, 0x7fff04693a30, MSG_CMSG_CLOEXEC) = 89 [pid 11028] recvmsg(5, 0x7fff04693a30, MSG_CMSG_CLOEXEC) = -1 EAGAIN (Resource temporarily unavailable) [pid 11028] sendmsg(5, 0x7fff04693c50, MSG_NOSIGNAL) = 128 [pid 11028] poll([?] 0x7fff04693d30, 1, 25000 I didn't wanted to attach a full strace because i'm not really sure what process i should trace, and that it might contain non public information. So if you would help me, to make any debug output that is filtered as much as possible, then i will share that. for example it would be good to know what file that they were polling... but i don't know how to extract that. And i assume, kde has a lot of debugging tools. So, thank you very much, i'm looking forward to help you debug this nasty one. Nasty because of course it disturbs the user, and nasty as it is random and not easily reproducible. Meta Reproducible: Sometimes Steps to Reproduce: I've described a few scenarios above. Actual Results: Freezing, and no response either from just the app, or either from the whole kde stack. But non KDE apps are never struggles with this. Expected Results: Seamless responses:)
I would like to mention, that i have disabled a few services, for example no desktop search and akonadi things, as i not really like this features, to be nice:) I have in my rc.local: chmod -x /usr/bin/akonadi* chmod -x /usr/bin/nepomuk* So for sure they stay silent, as there is no real way to completely disable them. (At least, there was none when i did this few years ago, now there is a few checkboxes in systemsettings, i have them off too.) But because it is basically working without them (not dies instantly, and doesn't refuse to start things up) i don't really think this causes the problem, but you might know it better. And i forgot to mention in the description, that this doesn't look good either: meta@x220:~$ ps aux | grep kded meta 1855 0.0 0.3 1218588 28496 ? Sl 09:32 0:00 kdeinit4: kded4 [kdeinit] meta 2361 0.0 0.2 349296 17968 ? Sl 09:32 0:00 kdeinit4: kded4 [kdeinit] meta 2415 0.0 0.2 349292 17912 ? Sl 09:32 0:00 kdeinit4: kded4 [kdeinit] meta 5456 0.0 0.2 349292 17916 ? Sl 09:35 0:00 kdeinit4: kded4 [kdeinit] meta 5641 0.0 0.2 349956 18820 ? Sl 09:35 0:00 kdeinit4: kded4 [kdeinit] meta 5850 0.0 0.2 349296 17964 ? Sl 09:35 0:00 kdeinit4: kded4 [kdeinit] meta 6714 0.0 0.2 275680 17360 ? S 09:40 0:00 kdeinit4: kded4 [kdeinit] meta 6753 0.0 0.0 159920 5592 ? S 09:40 0:00 kdeinit4: kded4 [kdeinit] meta 6754 0.0 0.0 0 0 ? Z 09:40 0:00 [kded4] <defunct> meta 6827 0.0 0.0 159920 5592 ? S 09:41 0:00 kdeinit4: kded4 [kdeinit] meta 6828 0.0 0.0 0 0 ? Z 09:41 0:00 [kded4] <defunct> meta 6882 0.0 0.0 159920 5596 ? S 09:41 0:00 kdeinit4: kded4 [kdeinit] meta 6883 0.0 0.0 0 0 ? Z 09:41 0:00 [kded4] <defunct> meta 6891 0.0 0.0 159920 5592 ? S 09:41 0:00 kdeinit4: kded4 [kdeinit] meta 6892 0.0 0.0 0 0 ? Z 09:41 0:00 [kded4] <defunct> meta 6894 0.0 0.0 159920 5596 ? S 09:41 0:00 kdeinit4: kded4 [kdeinit] meta 6895 0.0 0.0 0 0 ? Z 09:41 0:00 [kded4] <defunct> meta 6918 0.0 0.0 159920 5604 ? S 09:42 0:00 kdeinit4: kded4 [kdeinit] meta 6919 0.0 0.0 0 0 ? Z 09:42 0:00 [kded4] <defunct> meta 7196 0.0 0.0 159920 5596 ? S 09:52 0:00 kdeinit4: kded4 [kdeinit] meta 7197 0.0 0.0 0 0 ? Z 09:52 0:00 [kded4] <defunct> meta 7424 0.0 0.0 159920 5596 ? S 09:53 0:00 kdeinit4: kded4 [kdeinit] meta 7425 0.0 0.0 0 0 ? Z 09:53 0:00 [kded4] <defunct> meta 7588 0.0 0.2 275508 17660 ? S 09:54 0:00 kdeinit4: kded4 [kdeinit] meta 7861 0.0 0.2 275572 17652 ? S 09:55 0:00 kdeinit4: kded4 [kdeinit] meta 10105 0.0 0.0 159920 5596 ? S 12:01 0:00 kdeinit4: kded4 [kdeinit] meta 10106 0.0 0.0 0 0 ? Z 12:01 0:00 [kded4] <defunct> meta 10433 0.0 0.0 159920 5596 ? S 12:16 0:00 kdeinit4: kded4 [kdeinit] meta 10434 0.0 0.0 0 0 ? Z 12:16 0:00 [kded4] <defunct> meta 11259 0.0 0.0 10940 980 pts/17 S+ 13:06 0:00 grep --color=auto kded Breaking news: I wanted to do a screenshot from my services statusses, and systemsettings thrrew a modal dialog after 10 minits of freezing: "Unable to contact KDED."
Created attachment 83352 [details] My kde services meta@x220:~$ kde4-config --version Qt: 4.8.4 KDE Development Platform: 4.11.2 kde4-config: 1.0 I needed to relogin to be able to open this panel in systemsettings. Now it is just: meta@x220:~$ ps aux | grep kded meta 11625 0.3 0.4 1396740 34748 ? Sl 13:09 0:00 kdeinit4: kded4 [kdeinit] meta 12001 0.0 0.2 275584 17668 ? S 13:09 0:00 kdeinit4: kded4 [kdeinit] meta 12233 0.0 0.0 10940 980 pts/2 S+ 13:12 0:00 grep --color=auto kded
It looks like one of the kded4 modules causes issues. Please try to disable modules to find the culprit. Not every module can be disabled from the GUI. For more information, please read http://kdepepo.wordpress.com/2011/05/11/troubleshooting-kded4-bugs/ Also make sure you only have one kded4 process running. Using "killall kded4", then later running "kded4" should only result in one process. If in doubt, reboot.
Thank you! I have disabled as much as i was dare, i'm waiting to see the results. On the other hand, i have found - at least one source - where the new kded processes are coming. I have an own acpi script (i made it), which handles my notebooks buttons, and this starts an application like the following: su -c GTK2_RC_FILES=/data/home/meta/.gtkrc-2.0-kde:/data/home/meta/.gtkrc-2.0-kde4:/data/home/meta/.kde/share/config/gtkrc-2.0 GTK_RC_FILES=/etc/gtk/gtkrc:/data/home/meta/.gtkrc:/data/home/meta/.kde/share/config/gtkrc:/data/home/meta/.kde/share/config/gtkrc-2.0 GS_LIB=/data/home/meta/.fonts GTK_RC_FILES=/etc/gtk/gtkrc:/data/home/meta/.gtkrc-1.2-gnome2 DISPLAY=:0 XAUTHORITY=/data/home/meta/.Xauthority export $(dbus-launch) ; SSH_ASKPASS=/usr/bin/ksshaskpass; eval $(ssh-agent -s); ssh-add < /dev/null; sleep 2 && tail -n 1 /tmp/acpi_thinkvantage | bash Where: meta@x220:~$ cat /tmp/acpi_thinkvantage 1383730996.0956 0 thunderbird (The sleep part is because if i press the button twice, the file's content changing, so this way if i press a button once thunderbird starts, if twice then krusader... Crazy, i know.) So the command is this big, because acpi runs as root, and knows nothing about X, kde, dbus or anything. So quite a bit of bootstrap needed to have a correct looking, and correctly functioning x app started from there, that also can login to ssh without asking password. From the above command dbus-launch seems to start kded4 , i've tested it. I don't know how to prevent dbus from launching new kdeds, do you have any idea? Maybe the problem is the many kdeds can not access the same resource? How can i solve that dbus-launch would use an existing kded session?
I think i have sorted out the dbus-launch command with: grep -E "^DBUS_SESSION_BUS_ADDRESS" `find "${HOME}/.dbus/session-bus/" -type f` This way i'll get the DBUS_SESSION_BUS_ADDRESS as i would have from X, and it seems to work, but still kded4's starting up, after a reboot now i'm having 3. Any idea?
Okay, i have fixed my acpi script, and i have disabled many services, and now the freezes gone. Still i have issues with more than one kded starting up but not as many as before. So i have this: meta@x220:~$ ls -1v /usr/share/kde4/services/kded/ device_automounter.desktop keyboard.desktop khotkeys.desktop kmixd.desktop kpasswdserver.desktop kssld.desktop ktimezoned.desktop kwrited.desktop networkstatus.desktop networkwatcher.desktop notificationhelper.desktop phononserver.desktop plasmanm.desktop powerdevil.desktop printmanager.desktop recentdocumentsnotifier.desktop soliduiserver.desktop statusnotifierwatcher.desktop And here is the disabled ones: meta@x220:~$ ls -1v /usr/share/kde4/services/nemkded/ appmenu.desktop bluedevil.desktop colord.desktop desktopnotifier.desktop dnssdwatcher.desktop favicons.desktop freespacenotifier.desktop kcookiejar.desktop kephal.desktop konqy_preloader.desktop kscreen.desktop ktouchpadenabler.desktop ktp_approver.desktop muon-notifier.desktop nepomuksearchmodule.desktop obexftpdaemon.desktop proxyscout.desktop remotedirnotify.desktop solidautoeject.desktop wacomtablet.desktop Could you give me an order from the disabled ones, in which i should try to start to re-enable them one-by-one and wait for freezes? Actually i'm happy that i have no more freezes, and i don't need anything that i disabled, so i could close this, but if someone wants to take care of this and debug, i can try to enable them one-by-one. Or maybe for first reenable all of them to see if the problem is between them at all. Anyone?
I don't Know if that thread is the correct for my comment. I'm running Kubuntu 14.04 on desktop computer In Windows the hardware components functioned normally In Kubuntu 13.10, that I ran previously: Every few minutes the system freezes, and then after perhaps 30 seconds or so it recover. There's nothing to be seen in /var/log/syslog (via KSystemLog). The mouse, however, continues to move the cursor. Even Alt-F1, Ctrl-Alt-Del doesn't work during the freeze. The system load seems reasonable—no sign of excessive CPU or RAM usage In Kubuntu 14.04, raises the same problem that had kubuntu 13.10 but not with the same intensity and duration. However exhibits almost the same frequency. Hardware Info m/b: ASUS M4A78T-E, AMD Phenom II X3 720 Processor , graphic: AtiRadeonHD5450, Memory: 6GB – CORSAIR DDR3 (3X2GB) PC3-10666 (1333MHZ) System Info Kernel : Linux 3.13.0-2-generic (x86_64) Compiled : #17-Ubuntu SMP Fri Jan 10 12:14:30 UTC 2014 C Library : Unknown Default C Compiler : GNU C Compiler version 4.8.2 20140110 (prerelease) [ibm/gcc-4_8-branch merged from gcc-4_8-branch, revision 205847] (Ubuntu/Linaro 4.8.2-13ubuntu1) Distribution : Ubuntu Trusty Tahr (development branch)
If Ctrl+Alt+F1 does not work, the freeze is inside the kernel. Please report this issue to the bug tracker of your distribution. KDE applications cannot prevent the console switch from happening.
Dear Bug Submitter, This bug has been stagnant for a long time. Could you help us out and re-test if the bug is valid in the latest version? I am setting the status to NEEDSINFO pending your response, please change the Status back to REPORTED when you respond. Thank you for helping us make KDE software even better for everyone!
Dear Bug Submitter, This is a reminder that this bug has been stagnant for a long time. Could you help us out and re-test if the bug is valid in the latest version? This bug will be moved back to REPORTED Status for manual review later, which may take a while. If you are able to, please lend us a hand. Thank you for helping us make KDE software even better for everyone!
No response; assuming it was fixed since then.