I'm working on a small application and I need to find the PID of a process given the X11 window ID of its main window or child windows. I saw examples for doing such a conversion using _NET_WM_PID
, but I cannot figure out how to do it without using it. The reason for not using _NET_WM_PID
is that it's not implemented in all the available window managers and my application needs to work on any one of them (or at least on most of them). Could somebody help me please and give me some suggestion/directions on how to solve this issue? Thank you!
In general, it's not possible to find out the PID of a process that created a window. It may be that the process is running remotely on a machine, and it may be that the machine doesn't even have the notion of processes and PIDs.
If you don't trust anybody stored this information when the client was originally created, you will need to trace the connections yourself. Find out what kind of connection (socket etc) the client was using, find out where that connection ends, and find out which process holds that end. How to do that (and whether it is possible at all) is highly operating system dependent.
Unless your X-server supports XResQueryClientIds
from X-Resource v1.2 extension I know no easy way to reliably request process ID. There're other ways however.
If you just have a window in front of you and don't know its ID yet — it's easy to find it out. Just open a terminal next to the window in question, run xwininfo
there and click on that window. xwininfo
will show you the window-id.
So let's assume you know a window-id, e.g. 0x1600045, and want to find, what's the process owning it.
The easiest way to check who that window belongs to is to run XKillClient for it i.e.:
xkill -id 0x1600045
and see what process have just died. Of course if you don't mind it to die.
Another easy but unreliable way is to check its _NET_WM_PID
and WM_CLIENT_MACHINE
properties:
xprop -id 0x1600045
That's what tools like xlsclients
and xrestop
do.
Unfortunately this information may be incorrect not only because the process was evil and changed those, but also because it was buggy. For example after some firefox crash/restart I've seen orphaned windows (from flash plugin, I guess) with _NET_WM_PID
pointing to a process, that died long time ago.
Alternative way is to run
xwininfo -root -tree
and check properties of parents of the window in question. That may also give you some hints about window origins.
But! While you may not find what process have created that window, there's still a way to find where that process have connected to X-server from. And that way is for real hackers. :)
The window-id 0x1600045 that you know with lower bits zeroed (i.e. 0x1600000) is a "client base". And all resource IDs, allocated for that client are "based" on it (0x1600001, 0x1600002, 0x1600003, etc). X-server stores information about its clients in clients[] array, and for each client its "base" is stored in clients[i]->clientAsMask variable. To find X-socket, corresponding to that client, you need to attach to X-server with gdb
, walk over clients[] array, find client with that clientAsMask
and print its socket descriptor, stored in ((OsCommPtr)(clients[i]->osPrivate))->fd.
There may be many X-clients connected, so in order to not check them all manually, let's use a gdb function:
define findclient
set $ii = 0
while ($ii < currentMaxClients)
if (clients[$ii] != 0 && clients[$ii]->clientAsMask == $arg0 && clients[$ii]->osPrivate != 0)
print ((OsCommPtr)(clients[$ii]->osPrivate))->fd
end
set $ii = $ii + 1
end
end
When you find the socket, you can check, who's connected to it, and finally find the process.
WARNING: Do NOT attach gdb to X-server from INSIDE the X-server. gdb suspends the process it attaches to, so if you attach to it from inside X-session, you'll freeze your X-server and won't be able to interact with gdb. You must either switch to text terminal (Ctrl+Alt+F2
) or connect to your machine over ssh.
Example:
Find the PID of your X-server:
$ ps ax | grep X 1237 tty1 Ssl+ 11:36 /usr/bin/X :0 vt1 -nr -nolisten tcp -auth /var/run/kdm/A:0-h6syCa
Window id is 0x1600045, so client base is 0x1600000. Attach to X-server and find client socket descriptor for that client base. You'll need debug information installed for X-server (-debuginfo package for rpm-distributions or -dbg package for deb's).
$ sudo gdb (gdb) define findclient Type commands for definition of "findclient". End with a line saying just "end". > set $ii = 0 > while ($ii < currentMaxClients) > if (clients[$ii] != 0 && clients[$ii]->clientAsMask == $arg0 && clients[$ii]->osPrivate != 0) > print ((OsCommPtr)(clients[$ii]->osPrivate))->fd > end > set $ii = $ii + 1 > end > end (gdb) attach 1237 (gdb) findclient 0x1600000 $1 = 31 (gdb) detach (gdb) quit
Now you know that client is connected to a server socket 31. Use
lsof
to find what that socket is:$ sudo lsof -n | grep 1237 | grep 31 X 1237 root 31u unix 0xffff810008339340 8512422 socket
(here "X" is the process name, "1237" is its pid, "root" is the user it's running from, "31u" is a socket descriptor)
There you may see that the client is connected over TCP, then you can go to the machine it's connected from and check
netstat -nap
there to find the process. But most probably you'll see a unix socket there, as shown above, which means it's a local client.To find a pair for that unix socket you can use the MvG's technique (you'll also need debug information for your kernel installed):
$ sudo gdb -c /proc/kcore (gdb) print ((struct unix_sock*)0xffff810008339340)->peer $1 = (struct sock *) 0xffff810008339600 (gdb) quit
Now that you know client socket, use
lsof
to find PID holding it:$ sudo lsof -n | grep 0xffff810008339600 firefox 7725 username 146u unix 0xffff810008339600 8512421 socket
That's it. The process keeping that window is "firefox" with process-id 7725
In general, it's not possible to find out the PID of a process that created a window. It may be that the process is running remotely on a machine, and it may be that the machine doesn't even have the notion of processes and PIDs.
If you don't trust anybody stored this information when the client was originally created, you will need to trace the connections yourself. Find out what kind of connection (socket etc) the client was using, find out where that connection ends, and find out which process holds that end. How to do that (and whether it is possible at all) is highly operating system dependent.
Back in 2004, Harald Welte posted a code snippet that wraps the XCreateWindow() call via LD_PRELOAD and stores the process id in _NET_WM_PID. This makes sure that each window created has a useful _NET_WM_PID entry.
add a 0 after x in your_id to have 8 digits like 0xNNNNNNNN, then,
wmctrl -lp|grep "0x0$(printf "%x\n" *your_id*)"|awk '{print $3}'
© 2022 - 2024 — McMap. All rights reserved.
_NET_WM_PID
is set by the application, not by the window manager. – Nival