_NET_WM_PID
Właściwość EWMH, w której program zapisuje na oknie własny identyfikator procesu, aby menedżer okien wiedział, który proces zabić, gdy ping pozostaje bez odpowiedzi — samodeklaracja, której nikt nie weryfikuje.
Serwer X wie o procesie stojącym za połączeniem niewiele, a XKillClient zamyka tylko samo połączenie, więc zawieszony program spokojnie żyje dalej, choć stracił okna. Dlatego w 2000 roku EWMH dodał do właściwości okna głównego _NET_WM_PID, typu CARDINAL: program zapisuje tam swój PID, a menedżer okien, który po braku odpowiedzi na _NET_WM_PING chce sięgnąć po SIGKILL, go odczytuje — po porównaniu WM_CLIENT_MACHINE z własną nazwą hosta, bo PID z innej maszyny to przypadkowa liczba. GTK, Qt i xterm ustawiają go same; programy oparte na Xt i Motif nie, dlatego okno dialogowe KWin i GNOME Shell z propozycją wymuszonego zamknięcia bywa bezradne. Narzędzia poszły w ślad za tym: xprop _NET_WM_PID, xdotool getwindowpid i wmctrl -lp to to samo zapytanie, a paski zadań używają wartości do grupowania okien według procesu.
Ta właściwość to deklaracja, nie fakt. Program może wpisać, co zechce, a nie musi nawet kłamać, żeby się mylić: w kontenerze lub we Flatpaku proces żyje we własnej przestrzeni nazw PID i widzi inną liczbę niż menedżer okien. Prawdziwa tożsamość znajduje się w serwerze — dla klientów na gnieździe Uniksa jądro zna PID drugiej strony, a X-Resource w wersji 1.2 z 2011 roku pozwala klientowi zapytać serwer zamiast ufać oknu, co robi xrestop. Wayland uczynił to normą: kompozytor dostaje PID z gniazda w chwili połączenia i żaden klient nie ma szans wpisać własnego.