On Thu, 2018-11-08 at 17:25 +0000, Patrick O'Callaghan wrote: > On Wed, 2018-11-07 at 11:18 -0600, Rex Dieter wrote: > > Patrick O'Callaghan wrote: > > > > > 'kill <PID>' does kill it, but how do I run it again without logging > > > out? Simply running plasmashell from the command line does put up the > > > widget panel but it's still frozen, and the command never returns. > > > > You can (re)launch 'plasmashell' via krunner (ALT-F2) > > > > That said, may be worth trying to get a backtrace out of the deadlocked > > plasmashell process, if you have terminal access, run: > > > > gdb -p <PID> > > > > and issue command: > > thread apply all bt > > > > Getting a worthwhile backtrace may require installing -debuginfo packages, > > via something like: > > dnf debuginfo-install plasma-workspace > > (warning, it's a lot, but will give much better results) > > Another freeze, this time while I was using the machine. > > Gdb didn't give any results at all: > > $ pgrep -fl plasma > 7619 plasmashell > 9471 plasma-browser- > $ gdb -p 7619 > GNU gdb (GDB) Fedora 8.2-3.fc29 > Copyright (C) 2018 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> > This is free software: you are free to change and redistribute it. > There is NO WARRANTY, to the extent permitted by law. > Type "show copying" and "show warranty" for details. > This GDB was configured as "x86_64-redhat-linux-gnu". > Type "show configuration" for configuration details. > For bug reporting instructions, please see: > <http://www.gnu.org/software/gdb/bugs/>;;. > Find the GDB manual and other documentation resources online at: > <http://www.gnu.org/software/gdb/documentation/>;;. > > For help, type "help". > Type "apropos word" to search for commands related to "word". > Attaching to process 7619 > thread apply all bt > > That's it. gdb froze. I then did a Ctrl-Z and > > $ bg > $ pgrep gdb > 1049 > $ strace -p 1049 > strace: Process 1049 attached > wait4(7619, > > and again, that's it. So gdb is hung waiting for the plasmashell > process. This looks like a kernel-level hard wait. A look at 'ps' > shows: > > $ ps axl|grep plasmashell > ... > 0 1000 7619 1 20 0 3259992 102920 - Dl ? 0:57 /usr/bin/plasmashell > > so the WCHAN value is Dl Following up on this last, I wondered if the problem could be NFS- related. I have an NFS volume only used for backup and mounted from my NAS, so tried using 'fuser' to pin down what could be using it, but 'fuser' itself just sat there with no results. Curiouser and curiouser. I masked out the NFS mount from /etc/fstab and rebooted. I've now been running for 48 hours with no freezes or hangs, so I'm tentatively calling this an NFS bug. I might try re-enabling it using automount just for kicks. Not sure what else I can provide to BZ to make it debuggable, as plasmashell seems to be the only thing that triggers it. poc _______________________________________________ kde mailing list -- kde@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to kde-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kde@xxxxxxxxxxxxxxxxxxxxxxx
