I was running "kubuntu-devel-release-upgrade", but it crashed in the middle of the upgrade. Its window is still visible and unresponsive. When I try to close it, I get the usual warning: """ Application "ubuntu-release-upgrader" is not responding You tried to close window "Distribution Upgrade" from application "ubuntu-release-upgrader" (Process ID: 4176) but the application is not responding. """ However, process 4176 doesn't exist anymore. When I click "Terminate Application ...", nothing happens. I finally tried "xkill", and it worked. Reproducible: Didn't try Steps to Reproduce: (Don't have repro steps)
The process still exists, otherwise KWin would not be able to find its name :)
Client destruction after xkill invocation may be coincidental. Notice that kwin tries SIGTERM for local clients and uses "xon" (which i haven't even installed...) for remote ones (rather than XKillClient) Possible reasons: a) the client may require a more convincing SIGKILL b) the client process may belong to a different user ("ubuntu-release-upgrader" sounds like root) c) client indeed lost connection to server. @Christoph the application name is just the "resourceClass()" - we do not look up /proc (portability, i assume) For a remote client or a completely screwed X11 server, it *would* be possible to have a window for a client with lost connection. Since I however doubt either, I prefer answers a or b ;-)
I forgot to mention: I ran "ps 4176" to see what process was frozen, but "ps" couldn't find it, so I'm pretty sure the process was in fact gone.
Well, we cannot "fail" to kill a process that is gone. You didn't happen to check whether there was another PID for "ubuntu-release-upgrader", did you?
There was a "dpkg" process still running, which might have been the cause. I actually came up with a repro: """ #include <unistd.h> #include <QApplication> #include <QMainWindow> int main(int argc, char *argv[]) { QApplication app(argc, argv); QMainWindow w; w.show(); if (fork() == 0) { sleep(60); exit(0); } alarm(3); return app.exec(); } """ The application forks, then crashes. That's probably what ubuntu-release-upgrader did.
Many thanks. The reason is that _NET_WM_PID isn't updated on the window for the fork(), ie. is invalid. That's a NETWM violation, ie. client (in this case Qt) bug. xcb_kill_client just breaks the client/server connection, but doesn't actually kill the client (though the client *may* terminate in return), so actually ::kill() is the better variant for local connections and assumed legit PIDs, so we could if (::kill(pid, SIGTERM) != 0) xcb_kill_client(connection(), m_client); BUT: a) that doesn't necessarily kill the client b) we might still kill the wrong process for the false PID :-\
the connection is broken, the window closed - but the demo process is still running. My 2¢ - This is a client bug. - If killing the client fails (other than for EPERM), we should tell the user (resolving errno) and OFFER to simply break the client/server connection, WARNING that the process will likely not be killed and suggest to open ksysguard to isolate and kill the process instead. - Silently breaking the connection is not helpfull at all ---- https://bugreports.qt-project.org/browse/QTBUG-41664
I agree with the 2 cents from previous comment. I wouldn't mind us to improve the experience, in fact we could even open the process ui filtered on the window, but that would introduce a new dependency on the library. But I would also say that it's not a high priority as it's clearly a client bug if the pid is wrong.
This has been implemented afaict