jmozdzen wrote:

> it might be interesting to see in what state the iprint-listener-gui is,
> after killing it. Another thing you might want to try is to send it a
> different signal, like "SEGV" or even "9" after a short delay, since the
> process most likely already received the "original" INT, then blocked
> during handling that one, and now would need to be forced to terminate
> (which another "INT", the default signal, obviously doesn't do to this
> process).
> Does that process provide some mechanism to log details/debug? My guess
> is that the GUI process is waiting for iprint-listener to reappear,
> under the condition that sometimes the GUI is killed after* the
> listener. On the other occasions, the GUI is killed first and everything
> goes well... but it's just that, a guess

Actually I have no idea what this process does. I need it, because we
are using iPrint. I put this thread into the iPrint group as well hoping
to interest some expert there.
For the time being I'm sending a second "killall" and increased the
waiting time for the shutdown. For some days all installation where
fine. I will have to wait some more time in order to see if the problem
shows up again. I was not able to reproduce it in the lab.
I am well aware that this is nothing specific to iprint. Any user
initiated process that will not terminate properly upon logout and that
keeps files open in $HOME will result in the same problem.