_NET_WM_PING
Sposób, w jaki menedżer okien sprawdza, czy aplikacja się zawiesiła, oraz właściwość PID, dzięki której można potem ubić właściwy proces.
Serwer X nigdy nie zauważy, że program przestał odpowiadać: połączenie jest otwarte, okno narysowane, a kliknięcia grzecznie czekają w buforze serwera. EWMH dało menedżerowi okien test. Program, który wpisał _NET_WM_PING do WM_PROTOCOLS, dostaje co jakiś czas, a zawsze po kliknięciu przycisku zamykania, ClientMessage ze znacznikiem czasu i identyfikatorem własnego okna, który musi odesłać niezmieniony do okna głównego. Odpowiedź pochodzi z pętli zdarzeń programu, więc program tkwiący w obliczeniach lub blokującym wywołaniu nie odpowie, a po kilku sekundach menedżer może uznać, że się zawiesił. Stąd bierze się okno „aplikacja nie odpowiada” w Mutterze i KWinie. GTK i Qt odpowiadają na ping wewnątrz toolkitu, więc programista aplikacji nigdy go nie widzi.
Zabicie programu X jest trudniejsze, niż się wydaje. XKillClient tylko zamyka połączenie, a proces, który go nie nasłuchuje, będzie sobie żył dalej bez okna. Dlatego EWMH dodało też _NET_WM_PID na oknie, pozwalając menedżerowi wysłać SIGKILL do właściwego procesu po braku odpowiedzi — po uprzednim porównaniu WM_CLIENT_MACHINE z własną nazwą hosta, bo PID z innej maszyny nic nie znaczy. Kontenery i Flatpak z własnymi przestrzeniami nazw PID znów uczyniły tę sztuczkę zawodną, a lekcję wyciągnął Wayland: tam klient odpowiada na pingi w samym protokole, a kompozytor zna proces z gniazda.