http://bugzilla.opensuse.org/show_bug.cgi?id=1208892 Bug ID: 1208892 Summary: After period of idling: plasma desktop freezes and fxitx reports concomitantly two "zombie" instances". Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: x86-64 OS: openSUSE Tumbleweed Status: NEW Severity: Normal Priority: P5 - None Component: KDE Workspace (Plasma) Assignee: opensuse-kde-bugs@opensuse.org Reporter: stakanov@disroot.org QA Contact: qa-bugs@suse.de Found By: --- Blocker: --- Operating System: openSUSE Tumbleweed 20230228 KDE Plasma Version: 5.27.1 KDE Frameworks Version: 5.103.0 Qt Version: 5.15.8 Kernel Version: 6.2.0-1-default (64-bit) Graphics Platform: X11 Processors: 4 � AMD FX(tm)-4300 Quad-Core Processor Memory: 31.3 GiB of RAM Graphics Processor: AMD Radeon Pro W5500 Manufacturer: Gigabyte Technology Co., Ltd. entropy@localhost:~> rpm -qi fcitx5 Name : fcitx5 Version : 5.0.21 Release : 1.1 Architecture: x86_64 Install Date: mar 24 gen 2023, 17:46:47 Group : System/I18n/Chinese Size : 14902042 License : LGPL-2.1-or-later Signature : RSA/SHA256, ven 2 dic 2022, 13:54:01, Key ID b88b2fd43dbdc284 Source RPM : fcitx5-5.0.21-1.1.src.rpm Build Date : ven 2 dic 2022, 13:49:33 Build Host : lamb19 Packager : https://bugs.opensuse.org Vendor : openSUSE URL : https://github.com/fcitx/fcitx5 Summary : Next generation of fcitx Description : Fcitx 5 is a generic input method framework. Distribution: openSUSE Tumbleweed Situation: having two open user with their desktop, idling the machine on one desktop the active desktop will wake up, the other desktop will open (you can shift to it with e.g. cntrl+alt+Fn) but will be frozen. When this situation produces there is one particularity to be observed when doing a listing of open processes with ksysguard: fcitx5 on both desktop is a "zombie" process. While I can restart the fcitx on the "woke" desktop, the frozen one will not allow this, as programs cannot be selected and task bar does not show or respectively is not reactive. The mouse itself works normally with the desktop environment. The send sig term or sig kill to the process fcitx5 zombie does not have any effect (while after the restart fcitx on the woke desktop does work). The zombie is sometimes only on the blocked desktop, sometimes it happens also to the woke/active desktop (were active is the desktop that was active at the time of idling). I am not sure that it is fcitx the "culprit" to be clear. But that would be maybe a way to start to debug, because AFAIK the zombie processes appear only in these situations and are connected with the problem in some way. The problem is present with at least one application open that uses fcitx input (I did not try or reproduce it without any application open, which is also somewhat difficult with plasma, something somewhere is always open). Generally I have Kontact open, with or without an instance of Opera. After terminating the whole blocked desktop (no reaction on alt+ctrl+del) no logout electable, hence killing the processes of that user by use of kysguard on the normally active user) the killed user can start the desktop again without issues and work normally. Fcitx on this machine is used for Chinese language support (simplified and m17n pinyin). What the software should do: survive idling and wake up from it functional. -- You are receiving this mail because: You are on the CC list for the bug.