ICE default IO error handler doing an exit(), pid

问题:

One of our PyQt app throwa an error about ICEAuthority as below and exit -

ICE default IO error handler doing an exit(), pid = 11281, errno = 4

On looking at the trace, we see the following -

write(25, "\1\0\3\200\3\0\0\0\3\0\0\0\t\0\0\0\10\0\0\0\1\0\0\0\377rtStyle", 32) = 32
read(25, 0x16a67f0, 8) = ? ERESTARTSYS (To be restarted)
— SIGCHLD (Child exited) @ 0 (0) —
write(6, "\0", 1) = 1
rt_sigreturn(0x2) = -1 EINTR (Interrupted system call)
write(2, "ICE default IO error handler doi"..., 69) = 69

This looks like the ICEAuthority file read operation failed to restart after handling the SIGCHLD for one of the processes we spawned from the PyQt app. On googling, there are a lot of reports about ICEAuthority file failure and people suggest restarting the system, deleting the .ICEAuthority file, or unsetting SESSION_MANAGER. We are inclined to unset SESSION_MANAGER in our PyQt app for now. But I'd like to understand why the operation failed to restart the read operation of the ICEAuthority file. Is this a bug in the gnome-session code? Is anyone aware of it?

Also I'd like to mention that I tried setting SA_RESTART to false for the SIGCHLD handle to restart the operation. This failed to work.

Please find below our system details -

Linux nyc-nx-l01.schrodinger.com 2.6.32-358.23.2.el6.x86_64 #1 SMP Wed Oct 16 18:37:12 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

CentOS release 6.4 (Final)

回答1:

I had the same error message when starting 'keepassx' on Ubuntu. Deleting my ~/.ICEauthority file fixed it. Only deleted it once, have never had the problem since.

回答2:

In my linux machine USB was not readable, and then kile was also showing the error "ICE default IO error handler doing an exit(), pid = 11212, errno = 0".

Deleting the file .ICEauthority, worked for me.

回答3:

I do not think there is a problem deleting the .ICEauthority file. That folder holds torrent cookies probably from a private tracker or something. I still believe ktorrent is one of the best torrent clients because it gives a timeout time to stagnate torrents and tries to load up active ones. In other words, the client always tries to make sure it is working with active torrent sources.