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.