KDE applications fail to query file system - ICE default IO error handler doing an exit(), pid = XXX

Puneet_Singh · January 17, 2024, 9:09am

Hi All,
I have a CentOS 7 based XFCE session (say server1:11) on a server. I am having issues in launching some KDE applications (kdirstat,kwrite,dolphin) which query file systems information to display file system in browsers.

Here are the applications and the issues i faced with each of them.
i.e.
kwrite - works fine until we dont click on Open button. Open buttondisplays file system information but after 3-4 minutes (attached image)

kdirstat : fails to run - hangs up first and then terminates after 4-5 minutes with error - (attached image)

[user@server1]~>kdirstat
ICE default IO error handler doing an exit(), pid = 93710, errno = 32

dolphin : fails to run , command blocks for 2-3 minutes, UI pops and dissapears immidiately and i see following on terminal –
error message

[user@server1]~>dolphin 
ICE default IO error handler doing an exit(), pid = 99761, errno = 32
kDebugStream called after destruction (from void KDirWatchPrivate::removeWatch(KDirWatchPrivate::Entry*) file kdelibs-4.14.8/kdecore/io/kdirwatch.cpp line 973)
Cancelled FAM (Req 1) for "/home/user/.local/share/user-places.xbel"
[user@server]~>

konqueror : runs but when we do File> Open File Browser then it the FIle option becomes inactive ( does not respond to further clicks) and it takes ~4-5 minutes for file open dialog to appear.
(attached image)

It appears that there is some issue with The way KDE libraries are pulling the file system information for the dialog box.

I noticed following with strace on the dolphin -

poll([{fd=7, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{fd=7, revents=POLLOUT}])
writev(7, [{iov_base="\22\0\v\0\25\0 \28\1\0\08\1\0\0 on/\5\0\0\0\3\0\0\0>\0\0\0"..., iov_len=68}, {iov_base=NULL, iov_len=0}, {iov_base="", iov_len=0}], 3) = 68
poll([{fd=7, events=POLLIN}], 1, -1)    = 1 ([{fd=7, revents=POLLIN}])
recvmsg(7, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="\34\0\24\2\25\0 \28\1\0\0\230\201,\246\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., iov_len=4096}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, 0) = 64
recvfrom(7, "\1\0\0\0", 4, 0, NULL, NULL) = 4
poll([{fd=7, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{fd=7, revents=POLLOUT}])
writev(7, [{iov_base="\24\0\6\0\25\0 \2\r\1\0\0\4\0\0\0\0\0\0\0\0\10\0\0", iov_len=24}, {iov_base=NULL, iov_len=0}, {iov_base="", iov_len=0}], 3) = 24
poll([{fd=7, events=POLLIN}], 1, -1)    = 1 ([{fd=7, revents=POLLIN}])
recvmsg(7, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="\1 \26\2\1\0\0\0\4\0\0\0\0\0\0\0\1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0", iov_len=4096}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, 0) = 32
recvfrom(7, 0x6b6f010, 4, 0, NULL, NULL) = -1 EAGAIN (Resource temporarily unavailable)
poll([{fd=7, events=POLLIN}], 1, -1)    = 1 ([{fd=7, revents=POLLIN}])
recvfrom(7, "0\1\0\0", 4, 0, NULL, NULL) = 4
write(4, "\1\0\0\0\0\0\0\0", 8)         = 8
write(4, "\1\0\0\0\0\0\0\0", 8)         = 8
read(15, "\1\3\0\1\1\0\0\0", 8)         = 8
read(15, "\1\0\0\0002739", 8)           = 8
write(15, "\1\f\1\0\10\0\0\0\1\0\0\0\0\0\0\0\7\0\0\0Program\0\0\0\0\0"..., 72) = -1 EPIPE (Broken pipe)
--- SIGPIPE {si_signo=SIGPIPE, si_code=SI_USER, si_pid=232464, si_uid=5516} ---
write(2, "ICE default IO error handler doi"..., 71ICE default IO error handler doing an exit(), pid = 232464, errno = 32
) = 71
sendmsg(16, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="l\1\1\1m\0\0\0\232\23\0\0\177\0\0\0\1\1o\0\25\0\0\0/org/fre"..., iov_len=144}, {iov_base="h\0\0\0type='signal',path='/KIO/Sch"..., iov_len=109}], msg_iovlen=2, msg_controllen=0, msg_flags=0}, MSG_NOSIGNAL) = 253
sendmsg(16, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="l\1\1\1j\0\0\0\233\23\0\0\177\0\0\0\1\1o\0\25\0\0\0/org/fre"..., iov_len=144}, {iov_base="e\0\0\0type='signal',path='/KIO/Sch"..., iov_len=106}], msg_iovlen=2, msg_controllen=0, msg_flags=0}, MSG_NOSIGNAL) = 250
write(4, "\1\0\0\0\0\0\0\0", 8)         = 8
write(4, "\1\0\0\0\0\0\0\0", 8)         = 8
write(17, "\n\0\1\0\2\0\3\0\0\0", 10)   = 10
sendmsg(16, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="l\4\1\1\27\0\0\0\234\23\0\0O\0\0\0\1\1o\0\1\0\0\0/\0\0\0\0\0\0\0"..., iov_len=96}, {iov_base="\22\0\0\0file:///home/user\0", iov_len=23}], msg_iovlen=2, msg_controllen=0, msg_flags=0}, MSG_NOSIGNAL) = 119
sendmsg(16, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="l\1\1\1F\0\0\0\235\23\0\0\177\0\0\0\1\1o\0\25\0\0\0/org/fre"..., iov_len=144}, {iov_base="A\0\0\0type='signal',interface='org"..., iov_len=70}], msg_iovlen=2, msg_controllen=0, msg_flags=0}, MSG_NOSIGNAL) = 214
sendmsg(16, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="l\1\1\1E\0\0\0\236\23\0\0\177\0\0\0\1\1o\0\25\0\0\0/org/fre"..., iov_len=144}, {iov_base="@\0\0\0type='signal',interface='org"..., iov_len=69}], msg_iovlen=2, msg_controllen=0, msg_flags=0}, MSG_NOSIGNAL) = 213
sendmsg(16, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="l\1\1\1G\0\0\0\237\23\0\0\177\0\0\0\1\1o\0\25\0\0\0/org/fre"..., iov_len=144}, {iov_base="B\0\0\0type='signal',interface='org"..., iov_len=71}], msg_iovlen=2, msg_controllen=0, msg_flags=0}, MSG_NOSIGNAL) = 215
sendmsg(16, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="l\1\1\1G\0\0\0\240\23\0\0\177\0\0\0\1\1o\0\25\0\0\0/org/fre"..., iov_len=144}, {iov_base="B\0\0\0type='signal',interface='org"..., iov_len=71}], msg_iovlen=2, msg_controllen=0, msg_flags=0}, MSG_NOSIGNAL) = 215
close(22)                               = 0
write(4, "\1\0\0\0\0\0\0\0", 8)         = 8
sendmsg(16, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="l\1\1\1D\0\0\0\241\23\0\0\177\0\0\0\1\1o\0\25\0\0\0/org/fre"..., iov_len=144}, {iov_base="?\0\0\0type='signal',interface='org"..., iov_len=68}], msg_iovlen=2, msg_controllen=0, msg_flags=0}, MSG_NOSIGNAL) = 212
write(17, "\n\0\1\0\1\0\3\0\0\0", 10)   = 10
write(2, "kDebugStream called after destru"..., 160kDebugStream called after destruction (from void KDirWatchPrivate::removeWatch(KDirWatchPrivate::Entry*) file kdelibs-4.14.8/kdecore/io/kdirwatch.cpp line 973)
) = 160
write(2, "Cancelled FAM (Req 1) for \"/home"..., 70Cancelled FAM (Req 1) for "/home/user/.local/share/user-places.xbel"
) = 70

with k4dirstat as well i noticed similar behavior where the kdirstat terminated and i noticed SIGPIPE as the reason while attempting write on fd/socket#15 .

readlinkat(AT_FDCWD, "/sys/devices/pci0000:57/0000:57:02.0/0000:58:00.0/host14/port-14:0/end_device-14:0/target14:0:0/14:0:0:0/block/sda/sda2/subsystem", "../../../../../../../../../../.."..., 99) = 47
open("/run/udev/data/b8:2", O_RDONLY|O_CLOEXEC) = 25
fstat(25, {st_mode=S_IFREG|0644, st_size=1287, ...}) = 0
fstat(25, {st_mode=S_IFREG|0644, st_size=1287, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f90a1609000
read(25, "S:disk/by-id/scsi-35002538a4824b"..., 4096) = 1287
read(25, "", 4096)                      = 0
close(25)                               = 0
munmap(0x7f90a1609000, 4096)            = 0
getrandom("\xd9\xb0\x9a\xde\xeb\x24\xa6\xdd\xf8\x4b\x47\x7b\x6b\xe7\xee\x7c", 16, GRND_NONBLOCK) = 16
getrandom("\x1b\x8c\xb6\xf9\xb7\x17\x1c\x9e\x0a\x3f\xb5\x85\xc7\x16\xf8\x6e", 16, GRND_NONBLOCK) = 16
getrandom("\x7d\x7e\x2d\x9e\xe2\xb4\xae\xec\xa7\x31\x8c\x79\xe9\xfb\x73\x23", 16, GRND_NONBLOCK) = 16
write(4, "\1\0\0\0\0\0\0\0", 8)         = 8
read(15, "\1\3\0\1\1\0\0\0", 8)         = 8
read(15, "\1\0\0\0002588", 8)           = 8
write(15, "\1\f\1\0\10\0\0\0\1\0\0\0\0\0\0\0\7\0\0\0Program\0\0\0\0\0"..., 72) = -1 EPIPE (Broken pipe)
--- SIGPIPE {si_signo=SIGPIPE, si_code=SI_USER, si_pid=4166, si_uid=5516} ---
write(2, "ICE default IO error handler doi"..., 69ICE default IO error handler doing an exit(), pid = 4166, errno = 32
) = 69
sendmsg(16, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="l\1\1\1j\0\0\0\22\0\0\0\177\0\0\0\1\1o\0\25\0\0\0/org/fre"..., iov_len=144}, {iov_base="e\0\0\0type='signal',path='/KIO/Sch"..., iov_len=106}], msg_iovlen=2, msg_controllen=0, msg_flags=0}, MSG_NOSIGNAL) = 250
sendmsg(16, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="l\1\1\1m\0\0\0\23\0\0\0\177\0\0\0\1\1o\0\25\0\0\0/org/fre"..., iov_len=144}, {iov_base="h\0\0\0type='signal',path='/KIO/Sch"..., iov_len=109}], msg_iovlen=2, msg_controllen=0, msg_flags=0}, MSG_NOSIGNAL) = 253
write(4, "\1\0\0\0\0\0\0\0", 8)         = 8

The non KDE applications like thunar, work fine as i am able to see the file system information immediately.

What could be the possible places i should start looking at for the debug? any configuration file (under i.e ~/.kde/) ? environment variable which could create issues with kde libs while accessing file system metadata?

Franken14679 · January 17, 2024, 11:31am

@Puneet_Singh:

Have you checked that, all available patches and updates have been applied to your system?

Take a look at, the SUSE Enterprise support for CentOS (and RHEL) – <https://www.suse.com/products/suse-liberty-linux/>

Apart from that, you may well have to move on to another distribution …

Puneet_Singh · January 17, 2024, 12:32pm

Hi Franken,
Thank you for the reply.
We have following kernel version ( was patched ~3 months ago) 3.10.0-1160.88.1.el7.x86_64
Yes, We are planning to move to Rocky 9

There are10 other users on this server who dont face this issue, only a specific user is facing this issue. So, i am trying to root cause the issue. At the moment, I suspect some issue related to either kde process or configuration file (~/.kde?)

While checking today, i noticed that there were 2 kded4 processes running from the user’s account and it appears one of them is bad.

I think normally 1 kded4 process per user is expected to run. Could this be the root cause ? also, is there a safer way to determine and terminate defunct/troublesome KDE processes?

Franken14679 · January 17, 2024, 5:07pm

@Puneet_Singh:

Um, err, you’re still running KDE4? And, you’re still running a version 3.10 Linux Kernel?

The last KDE Software Compilation 4 release was released in November 2014 – that’s more than 9 years ago …
And the version 3.10 Linux Kernel was released in June 2013 – that’s more than 10 years ago.

I hope that, you realise just how many repairs have been made to the code over those 10 years?

Yes, Rocky 9.3 was released in November 2023 – you are well advised to move to that version but –

Please be aware that, due to the changes made by the KDE folks over the last 10 years, the migration will need some time and, careful migration of each user’s environment.

If any of your users are using the PIM applications – Mail, Calendar, Address Book – export everything to Archive directories on additional disk drives.

After the upgrade to Rocky 9 has been executed, before the user’s login again, move the contents of their ‘~/.config/’, ‘~/.local/’ and ‘~/.kde4/’ directories to Archive directories on additional disk drives. When each user logs in to the Rocky 9 systems, they’ll have to configure their new Desktop – KDE Plasma 5 – and, import their PIM data into the (new) PIM version which will appear after the upgrade has been performed.

Puneet_Singh · January 23, 2024, 7:05pm

Hi @Franken14679
Unfortunately yes, we are till bound to CentOS 7 as there are a lot of moving part in the production environment. This issue impacts only 1 user out of ~100 users, so there isnt very strong reason for making a disruptive change. Also, at the moment , we dont know the root cause of this issue , so We are not sure that KDE5 has fix for this issue.

I had analysed this further and i am at a stage where i understand the termination behavior

We had an observation that kdirstat application is terminated when it attempts to write to FD 15, the communication happens over ICE protocol and the remote end of this socket is xfce-session process

for some reason ,the kdirstat takes longer to communicate with the xfce-session , and when this happens, the xfce-session closes its end of socket due to SAVE TIMEOUT? -

nts=POLLIN}, {fd=21, events=POLLIN}, {fd=22, events=POLLIN}, {fd=23, events=POLLIN}, {fd=24, events=POLLIN}, {fd=25, events=POLLIN}], 16, 49865




) = 0 (Timeout)
write(14, "TRACE[xfsm-manager.c:1607] xfsm_manager_save_timeout(): Client id = 2a3d69b9c-99e3-4b71-b777-e453754cafab, received SAVE TIMEOUT\n   Client will be disconnected now.\n\n", 166) = 166
sendmsg(5, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="l\4\1\1\10\0\0\0\30\4\0\0\210\0\0\0\1\1o\0>\0\0\0/org/xfce/SessionClients/2a3d69b9c_99e3_4b71_b777_e453754cafab\0\0\2\1s\0\27\0\0\0org.xfce.Session.Client\0\3\1s\0\f\0\0\0StateChanged\0\0\0\0\10\1g\0\2uu\0", iov_len=152}, {iov_base="\4\0\0\0\7\0\0\0", iov_len=8}], msg_iovlen=2, msg_controllen=0, msg_flags=0}, MSG_NOSIGNAL) = 160
write(4, "\1\0\0\0\0\0\0\0", 8)         = 8
close(24)                               = 0
recvmsg(3, {msg_namelen=0}, 0)          = -1 EAGAIN (Resource temporarily unavailable)
recvmsg(3, {msg_namelen=0}, 0)          = -1 EAGAIN (Resource temporarily unavailable)
poll([{fd=3, events=POLLIN}, {fd=4, events=POLLIN}, {fd=5, events=POLLIN}, {fd=12, events=POLLIN}, {fd=13, events=POLLIN}, {fd=15, events=POLLIN}, {fd=16, events=POLLIN}, {fd=17, events=POLLIN}, {fd=18, events=POLLIN}, {fd=19, events=POLLIN}, {fd=20, events=POLLIN}, {fd=21, events=POLLIN}, {fd=22, events=POLLIN}, {fd=23, events=POLLIN}, {fd=25, events=POLLIN}], 15, -1) = 1 ([{fd=4, revents=POLLIN}])
read(4, "\1\0\0\0\0\0\0\0", 16)         = 8
recvmsg(3, {msg_namelen=0}, 0)          = -1 EAGAIN (Resource temporarily unavailable)
recvmsg(3, {msg_namelen=0}, 0)          = -1 EAGAIN (Resource temporarily unavailable)
poll([{fd=3, events=POLLIN}, {fd=4, events=POLLIN}, {fd=5, events=POLLIN}, {fd=12, events=POLLIN}, {fd=13, events=POLLIN}, {fd=15, events=POLLIN}, {fd=16, events=POLLIN}, {fd=17, events=POLLIN}, {fd=18, events=POLLIN}, {fd=19, events=POLLIN}, {fd=20, events=POLLIN}, {fd=21, events=POLLIN}, {fd=22, events=POLLIN}, {fd=23, events=POLLIN}, {fd=25, events=POLLIN}], 15, -1

and when kdirstat attempts to write into the socket, it receives SIGPIPE.

in the normal scenario (when kdirstat application is communicate with the xfce-session binary quickly ), here’s what xfce-session binary does -

Here is how i am able to reproduce this issue -
If i run the kdirstat with strace attached, example
strace -f -s 700 kdirstat
then kdirstat takes considerably longer time to communicate with xfce-session binary and program terminates with SIGPIPE.

I can see a lot of open calls for the /loop/…uevents file, and i suspect that kdirstat is taking longer to query the FS information for a particular user.

Is there a way to prevent xfce-session binary to disallow it to hold the connection for a longer duration? or any way to figure out why the KDE apps are taking longer time to query file system information?

Franken14679 · January 24, 2024, 11:23am

Does this misbehaviour also occur if the affected user uses a KDE4 session rather than an Xfce session?

Do you happen to have a copy of the Xfce source code for the version of Xfce you’re running?

Puneet_Singh · January 25, 2024, 6:01am

We have a NFS for $HOME so all files under $HOME are shared with multiple servers.

We tried running new XFCE session for the affected user on a different server and we did not see this issue there - so i if there are any common configurations fro KDE under $HOME, then they are good.

Plus there are some VNC sessions already running on same server, but those session do not see this issue. So there is nothing wrong with the server where user’s session is impacted.
So my assumption is that there is something wrong with (session specific) config data , or any running process related to xfce / QT which makes the KDE APi to take unusually longer time to get metadata information.

I tried killing off kded4 and deleted
$HOME/.kde/cache-server1
$HOME/.kde/tmp-server1
$HOME/.kde/socket-server1

these files were regerated on launching kded4 binary , but the SIGPIPE error still persists.

Here is the source code for the version of xfce-session binary i have
https://dl.fedoraproject.org/pub/epel/7/SRPMS/Packages/x/xfce4-session-4.12.1-8.el7.src.rpm

Franken14679 · January 25, 2024, 2:23pm

@Puneet_Singh:

Please note that, Xfce is not supported by the KDE community – you’ll have to ask for help repairing Xfce code by asking the Xfce community.

Or, instead of tying to repair outdated code, why not move the contents of the affected user’s home directory off to somewhere else and, create the basic home directories in the now empty affected user’s home directory by copying everything in ‘/etc/skel/’ over to the now empty directory –

Be aware that, by ALL directories I mean also the “hidden” directories –

 > LANG=C ls -alF /etc/skel/
total 76
drwxr-xr-x   7 root root  4096 Oct 25 09:42 ./
drwxr-xr-x 157 root root 12288 Jan 25 10:20 ../
-rw-------   1 root root     0 May 18  1996 .bash_history
-rw-r--r--   1 root root  1177 May  7  2022 .bashrc
drwx------   2 root root  4096 Mar 15  2022 .cache/
drwx------   2 root root  4096 Mar 15  2022 .config/
-rw-r--r--   1 root root  1637 Apr  9  2018 .emacs
drwxr-xr-x   2 root root  4096 Mar 15  2022 .fonts/
-rw-r--r--   1 root root    73 May 25  2018 .i18n
-rw-r--r--   1 root root   861 Apr  9  2018 .inputrc
drwx------   2 root root  4096 Mar 15  2022 .local/
-rw-r--r--   1 root root  6043 Sep 12 13:19 .muttrc
-rw-r--r--   1 root root  1028 May  7  2022 .profile
-rw-r--r--   1 root root   311 May 17  2023 .urlview
-rw-r--r--   1 root root  1951 May 25  2018 .xim.template
-rwxr-xr-x   1 root root  1112 May  5  2019 .xinitrc.template*
drwxr-xr-x   2 root root  4096 Mar 15  2022 bin/
 >

Please note that, the ‘/etc/skel/’ contents here are those on an openSUSE Leap 15.5 system – your distribution may well have other files in there and, also, the default protections may well be different …

Once the files have been copied over to the affected user’s home directory (cp --archive) change the ownership to that of the affected user – do not change the default file permissions.

Have the affected user login again and, allow Xfce to setup everything else it wants to setup.
Move only the affected user’s work files back to the new, clean, home directory – do not move any configuration or cached files back to that user’s clean home directory.

Have the user setup their environment one step at a time – after each setup step, have them test each of the KDE4 applications one after another to check if, an Xfce user environment setup was the root cause of the misbehaviour of the KDE4 applications …

Puneet_Singh · February 1, 2024, 11:20am

if i unset the SESSION_MANAGER variable, then this issue does not show up.
Any insights into what i may be trading off - if i am not using this variable?