What process created this X11 window?
Given an X11 window ID, is there a way to find the ID of the process that created it?
Of course this isn't always possible, for example if the window came over a TCP connection. For that case I'd like the IP and port associated with the remote end.
The question was asked before on Stack Overflow, and a proposed method was to use the _NET_WM_PID
property. But that's set by the application. Is there a way to do it if the application doesn't play nice?
process x11
add a comment |
Given an X11 window ID, is there a way to find the ID of the process that created it?
Of course this isn't always possible, for example if the window came over a TCP connection. For that case I'd like the IP and port associated with the remote end.
The question was asked before on Stack Overflow, and a proposed method was to use the _NET_WM_PID
property. But that's set by the application. Is there a way to do it if the application doesn't play nice?
process x11
Related: PID from window ID/name
– Gilles
Aug 29 '12 at 23:16
add a comment |
Given an X11 window ID, is there a way to find the ID of the process that created it?
Of course this isn't always possible, for example if the window came over a TCP connection. For that case I'd like the IP and port associated with the remote end.
The question was asked before on Stack Overflow, and a proposed method was to use the _NET_WM_PID
property. But that's set by the application. Is there a way to do it if the application doesn't play nice?
process x11
Given an X11 window ID, is there a way to find the ID of the process that created it?
Of course this isn't always possible, for example if the window came over a TCP connection. For that case I'd like the IP and port associated with the remote end.
The question was asked before on Stack Overflow, and a proposed method was to use the _NET_WM_PID
property. But that's set by the application. Is there a way to do it if the application doesn't play nice?
process x11
process x11
edited May 23 '17 at 12:40
Community♦
1
1
asked Jan 6 '11 at 21:07
GillesGilles
534k12810801597
534k12810801597
Related: PID from window ID/name
– Gilles
Aug 29 '12 at 23:16
add a comment |
Related: PID from window ID/name
– Gilles
Aug 29 '12 at 23:16
Related: PID from window ID/name
– Gilles
Aug 29 '12 at 23:16
Related: PID from window ID/name
– Gilles
Aug 29 '12 at 23:16
add a comment |
5 Answers
5
active
oldest
votes
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 which process just died. But only if you don't mind killing it of course!
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
2017 Edit: There are more options now as seen at Who's got the other end of this unix socketpair?. With Linux 3.3 or above and with lsof
4.89 or above, you can replace points 3 to 5 above with:
lsof +E -a -p 1237 -d 31
to find out who's at the other end of the socket on fd 31 of the X-server process with ID 1237.
4
Welcome the the Unix and Linux Stack Exchange! Your answer to this question is excellent. I hope you come back to answer more questions.
– user26112
Jul 31 '13 at 0:00
add a comment |
xdotool didn't work for me. This did:
Run
xprop _NET_WM_PID
and click on the window.
This is based on the answer at http://www.linuxquestions.org/questions/linux-software-2/advanced-question-finding-pid-of-an-x-window-328983/
Works for me when plugging in my Iphone brought up a non-responsive window prompt.
– modulitos
Oct 17 '14 at 5:43
1
Useful for evince that sometimes hung completely.kill $(xprop _NET_WM_PID|cut -d " " -f 3)
– Gabriel Devillers
Oct 9 '16 at 11:38
This is what I was looking for, xkill flow
– Rombus
Nov 2 '18 at 12:31
add a comment |
If you have xdotool installed, then
xdotool selectwindow getwindowpid
followed by clicking on the window in question will return the PID.
(There are other ways of selecting the window in question, e.g., if you have its window ID you can just do xdotool getwindowpid <number>
. You can also select by name or class, etc.)
I do think this requires some playing nice on behalf of the WM. I haven't experimented much, or needed to.
2
xdo_getwinprop(xdo, window, atom_NET_WM_PID, &nitems, &type, &size)
⇒ it's just a shell wrapper to read_NET_WM_PID
(useful, but not what I asked for).
– Gilles
Jan 6 '11 at 23:44
add a comment |
The _NET_WM_PID
isn't set by the window manager (as just another X11 client, how would it know?).
Instead, compliant X11 clients (applications) are expected to set _NET_WM_PID
and WM_CLIENT_MACHINE
on their own windows. Assuming a well-behaved application, this will be true whether a window manager is running or not.
If WM_CLIENT_MACHINE
is your own hostname, then the PID should be meaningful.
Otherwise, "I'd like the IP and port associated with the remote end" — I'm not sure what that means. For example, if you have an ssh session open with X forwarding enabled, windows opened by forwarded apps will be marked with remote PID and hostname, but you don't necessarily have any way to connect back to that remote host.
2
_NET_WM_PID
is set by the application: right, that does make more sense! But it's not the X11 protocol, it's the relatively recent FreeDesktop specification.
– Gilles
Jan 8 '11 at 12:26
In the ssh case, as far as the X server is concerned, this is a local connection from the sshd process. Though_NET_WM_PID
seems to be set to the remote PID andWM_CLIENT_MACHINE
to the remote connection (tested with xterm).
– Gilles
Jan 8 '11 at 12:26
add a comment |
I was able to use the xdotool
under Ubuntu 11.04 beta, but selectwindow
was not a valid command, I had to hack a script with:
$ while true; do sleep 1; xdotool getactivewindow; done
then watch the window ID go by while I selected the window I wanted, then decoded the responsible PID with:
$ xdotool getwindowpid <the-window-id>
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "106"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f5478%2fwhat-process-created-this-x11-window%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
5 Answers
5
active
oldest
votes
5 Answers
5
active
oldest
votes
active
oldest
votes
active
oldest
votes
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 which process just died. But only if you don't mind killing it of course!
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
2017 Edit: There are more options now as seen at Who's got the other end of this unix socketpair?. With Linux 3.3 or above and with lsof
4.89 or above, you can replace points 3 to 5 above with:
lsof +E -a -p 1237 -d 31
to find out who's at the other end of the socket on fd 31 of the X-server process with ID 1237.
4
Welcome the the Unix and Linux Stack Exchange! Your answer to this question is excellent. I hope you come back to answer more questions.
– user26112
Jul 31 '13 at 0:00
add a comment |
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 which process just died. But only if you don't mind killing it of course!
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
2017 Edit: There are more options now as seen at Who's got the other end of this unix socketpair?. With Linux 3.3 or above and with lsof
4.89 or above, you can replace points 3 to 5 above with:
lsof +E -a -p 1237 -d 31
to find out who's at the other end of the socket on fd 31 of the X-server process with ID 1237.
4
Welcome the the Unix and Linux Stack Exchange! Your answer to this question is excellent. I hope you come back to answer more questions.
– user26112
Jul 31 '13 at 0:00
add a comment |
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 which process just died. But only if you don't mind killing it of course!
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
2017 Edit: There are more options now as seen at Who's got the other end of this unix socketpair?. With Linux 3.3 or above and with lsof
4.89 or above, you can replace points 3 to 5 above with:
lsof +E -a -p 1237 -d 31
to find out who's at the other end of the socket on fd 31 of the X-server process with ID 1237.
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 which process just died. But only if you don't mind killing it of course!
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
2017 Edit: There are more options now as seen at Who's got the other end of this unix socketpair?. With Linux 3.3 or above and with lsof
4.89 or above, you can replace points 3 to 5 above with:
lsof +E -a -p 1237 -d 31
to find out who's at the other end of the socket on fd 31 of the X-server process with ID 1237.
edited Oct 12 '17 at 13:59
Stéphane Chazelas
304k57570927
304k57570927
answered Jul 30 '13 at 23:29
GuestGuest
64662
64662
4
Welcome the the Unix and Linux Stack Exchange! Your answer to this question is excellent. I hope you come back to answer more questions.
– user26112
Jul 31 '13 at 0:00
add a comment |
4
Welcome the the Unix and Linux Stack Exchange! Your answer to this question is excellent. I hope you come back to answer more questions.
– user26112
Jul 31 '13 at 0:00
4
4
Welcome the the Unix and Linux Stack Exchange! Your answer to this question is excellent. I hope you come back to answer more questions.
– user26112
Jul 31 '13 at 0:00
Welcome the the Unix and Linux Stack Exchange! Your answer to this question is excellent. I hope you come back to answer more questions.
– user26112
Jul 31 '13 at 0:00
add a comment |
xdotool didn't work for me. This did:
Run
xprop _NET_WM_PID
and click on the window.
This is based on the answer at http://www.linuxquestions.org/questions/linux-software-2/advanced-question-finding-pid-of-an-x-window-328983/
Works for me when plugging in my Iphone brought up a non-responsive window prompt.
– modulitos
Oct 17 '14 at 5:43
1
Useful for evince that sometimes hung completely.kill $(xprop _NET_WM_PID|cut -d " " -f 3)
– Gabriel Devillers
Oct 9 '16 at 11:38
This is what I was looking for, xkill flow
– Rombus
Nov 2 '18 at 12:31
add a comment |
xdotool didn't work for me. This did:
Run
xprop _NET_WM_PID
and click on the window.
This is based on the answer at http://www.linuxquestions.org/questions/linux-software-2/advanced-question-finding-pid-of-an-x-window-328983/
Works for me when plugging in my Iphone brought up a non-responsive window prompt.
– modulitos
Oct 17 '14 at 5:43
1
Useful for evince that sometimes hung completely.kill $(xprop _NET_WM_PID|cut -d " " -f 3)
– Gabriel Devillers
Oct 9 '16 at 11:38
This is what I was looking for, xkill flow
– Rombus
Nov 2 '18 at 12:31
add a comment |
xdotool didn't work for me. This did:
Run
xprop _NET_WM_PID
and click on the window.
This is based on the answer at http://www.linuxquestions.org/questions/linux-software-2/advanced-question-finding-pid-of-an-x-window-328983/
xdotool didn't work for me. This did:
Run
xprop _NET_WM_PID
and click on the window.
This is based on the answer at http://www.linuxquestions.org/questions/linux-software-2/advanced-question-finding-pid-of-an-x-window-328983/
answered Sep 10 '12 at 17:34
NoamNoam
461143
461143
Works for me when plugging in my Iphone brought up a non-responsive window prompt.
– modulitos
Oct 17 '14 at 5:43
1
Useful for evince that sometimes hung completely.kill $(xprop _NET_WM_PID|cut -d " " -f 3)
– Gabriel Devillers
Oct 9 '16 at 11:38
This is what I was looking for, xkill flow
– Rombus
Nov 2 '18 at 12:31
add a comment |
Works for me when plugging in my Iphone brought up a non-responsive window prompt.
– modulitos
Oct 17 '14 at 5:43
1
Useful for evince that sometimes hung completely.kill $(xprop _NET_WM_PID|cut -d " " -f 3)
– Gabriel Devillers
Oct 9 '16 at 11:38
This is what I was looking for, xkill flow
– Rombus
Nov 2 '18 at 12:31
Works for me when plugging in my Iphone brought up a non-responsive window prompt.
– modulitos
Oct 17 '14 at 5:43
Works for me when plugging in my Iphone brought up a non-responsive window prompt.
– modulitos
Oct 17 '14 at 5:43
1
1
Useful for evince that sometimes hung completely.
kill $(xprop _NET_WM_PID|cut -d " " -f 3)
– Gabriel Devillers
Oct 9 '16 at 11:38
Useful for evince that sometimes hung completely.
kill $(xprop _NET_WM_PID|cut -d " " -f 3)
– Gabriel Devillers
Oct 9 '16 at 11:38
This is what I was looking for, xkill flow
– Rombus
Nov 2 '18 at 12:31
This is what I was looking for, xkill flow
– Rombus
Nov 2 '18 at 12:31
add a comment |
If you have xdotool installed, then
xdotool selectwindow getwindowpid
followed by clicking on the window in question will return the PID.
(There are other ways of selecting the window in question, e.g., if you have its window ID you can just do xdotool getwindowpid <number>
. You can also select by name or class, etc.)
I do think this requires some playing nice on behalf of the WM. I haven't experimented much, or needed to.
2
xdo_getwinprop(xdo, window, atom_NET_WM_PID, &nitems, &type, &size)
⇒ it's just a shell wrapper to read_NET_WM_PID
(useful, but not what I asked for).
– Gilles
Jan 6 '11 at 23:44
add a comment |
If you have xdotool installed, then
xdotool selectwindow getwindowpid
followed by clicking on the window in question will return the PID.
(There are other ways of selecting the window in question, e.g., if you have its window ID you can just do xdotool getwindowpid <number>
. You can also select by name or class, etc.)
I do think this requires some playing nice on behalf of the WM. I haven't experimented much, or needed to.
2
xdo_getwinprop(xdo, window, atom_NET_WM_PID, &nitems, &type, &size)
⇒ it's just a shell wrapper to read_NET_WM_PID
(useful, but not what I asked for).
– Gilles
Jan 6 '11 at 23:44
add a comment |
If you have xdotool installed, then
xdotool selectwindow getwindowpid
followed by clicking on the window in question will return the PID.
(There are other ways of selecting the window in question, e.g., if you have its window ID you can just do xdotool getwindowpid <number>
. You can also select by name or class, etc.)
I do think this requires some playing nice on behalf of the WM. I haven't experimented much, or needed to.
If you have xdotool installed, then
xdotool selectwindow getwindowpid
followed by clicking on the window in question will return the PID.
(There are other ways of selecting the window in question, e.g., if you have its window ID you can just do xdotool getwindowpid <number>
. You can also select by name or class, etc.)
I do think this requires some playing nice on behalf of the WM. I haven't experimented much, or needed to.
answered Jan 6 '11 at 23:10
frabjousfrabjous
4,3371825
4,3371825
2
xdo_getwinprop(xdo, window, atom_NET_WM_PID, &nitems, &type, &size)
⇒ it's just a shell wrapper to read_NET_WM_PID
(useful, but not what I asked for).
– Gilles
Jan 6 '11 at 23:44
add a comment |
2
xdo_getwinprop(xdo, window, atom_NET_WM_PID, &nitems, &type, &size)
⇒ it's just a shell wrapper to read_NET_WM_PID
(useful, but not what I asked for).
– Gilles
Jan 6 '11 at 23:44
2
2
xdo_getwinprop(xdo, window, atom_NET_WM_PID, &nitems, &type, &size)
⇒ it's just a shell wrapper to read _NET_WM_PID
(useful, but not what I asked for).– Gilles
Jan 6 '11 at 23:44
xdo_getwinprop(xdo, window, atom_NET_WM_PID, &nitems, &type, &size)
⇒ it's just a shell wrapper to read _NET_WM_PID
(useful, but not what I asked for).– Gilles
Jan 6 '11 at 23:44
add a comment |
The _NET_WM_PID
isn't set by the window manager (as just another X11 client, how would it know?).
Instead, compliant X11 clients (applications) are expected to set _NET_WM_PID
and WM_CLIENT_MACHINE
on their own windows. Assuming a well-behaved application, this will be true whether a window manager is running or not.
If WM_CLIENT_MACHINE
is your own hostname, then the PID should be meaningful.
Otherwise, "I'd like the IP and port associated with the remote end" — I'm not sure what that means. For example, if you have an ssh session open with X forwarding enabled, windows opened by forwarded apps will be marked with remote PID and hostname, but you don't necessarily have any way to connect back to that remote host.
2
_NET_WM_PID
is set by the application: right, that does make more sense! But it's not the X11 protocol, it's the relatively recent FreeDesktop specification.
– Gilles
Jan 8 '11 at 12:26
In the ssh case, as far as the X server is concerned, this is a local connection from the sshd process. Though_NET_WM_PID
seems to be set to the remote PID andWM_CLIENT_MACHINE
to the remote connection (tested with xterm).
– Gilles
Jan 8 '11 at 12:26
add a comment |
The _NET_WM_PID
isn't set by the window manager (as just another X11 client, how would it know?).
Instead, compliant X11 clients (applications) are expected to set _NET_WM_PID
and WM_CLIENT_MACHINE
on their own windows. Assuming a well-behaved application, this will be true whether a window manager is running or not.
If WM_CLIENT_MACHINE
is your own hostname, then the PID should be meaningful.
Otherwise, "I'd like the IP and port associated with the remote end" — I'm not sure what that means. For example, if you have an ssh session open with X forwarding enabled, windows opened by forwarded apps will be marked with remote PID and hostname, but you don't necessarily have any way to connect back to that remote host.
2
_NET_WM_PID
is set by the application: right, that does make more sense! But it's not the X11 protocol, it's the relatively recent FreeDesktop specification.
– Gilles
Jan 8 '11 at 12:26
In the ssh case, as far as the X server is concerned, this is a local connection from the sshd process. Though_NET_WM_PID
seems to be set to the remote PID andWM_CLIENT_MACHINE
to the remote connection (tested with xterm).
– Gilles
Jan 8 '11 at 12:26
add a comment |
The _NET_WM_PID
isn't set by the window manager (as just another X11 client, how would it know?).
Instead, compliant X11 clients (applications) are expected to set _NET_WM_PID
and WM_CLIENT_MACHINE
on their own windows. Assuming a well-behaved application, this will be true whether a window manager is running or not.
If WM_CLIENT_MACHINE
is your own hostname, then the PID should be meaningful.
Otherwise, "I'd like the IP and port associated with the remote end" — I'm not sure what that means. For example, if you have an ssh session open with X forwarding enabled, windows opened by forwarded apps will be marked with remote PID and hostname, but you don't necessarily have any way to connect back to that remote host.
The _NET_WM_PID
isn't set by the window manager (as just another X11 client, how would it know?).
Instead, compliant X11 clients (applications) are expected to set _NET_WM_PID
and WM_CLIENT_MACHINE
on their own windows. Assuming a well-behaved application, this will be true whether a window manager is running or not.
If WM_CLIENT_MACHINE
is your own hostname, then the PID should be meaningful.
Otherwise, "I'd like the IP and port associated with the remote end" — I'm not sure what that means. For example, if you have an ssh session open with X forwarding enabled, windows opened by forwarded apps will be marked with remote PID and hostname, but you don't necessarily have any way to connect back to that remote host.
answered Jan 8 '11 at 4:18
ephemientephemient
11.6k53337
11.6k53337
2
_NET_WM_PID
is set by the application: right, that does make more sense! But it's not the X11 protocol, it's the relatively recent FreeDesktop specification.
– Gilles
Jan 8 '11 at 12:26
In the ssh case, as far as the X server is concerned, this is a local connection from the sshd process. Though_NET_WM_PID
seems to be set to the remote PID andWM_CLIENT_MACHINE
to the remote connection (tested with xterm).
– Gilles
Jan 8 '11 at 12:26
add a comment |
2
_NET_WM_PID
is set by the application: right, that does make more sense! But it's not the X11 protocol, it's the relatively recent FreeDesktop specification.
– Gilles
Jan 8 '11 at 12:26
In the ssh case, as far as the X server is concerned, this is a local connection from the sshd process. Though_NET_WM_PID
seems to be set to the remote PID andWM_CLIENT_MACHINE
to the remote connection (tested with xterm).
– Gilles
Jan 8 '11 at 12:26
2
2
_NET_WM_PID
is set by the application: right, that does make more sense! But it's not the X11 protocol, it's the relatively recent FreeDesktop specification.– Gilles
Jan 8 '11 at 12:26
_NET_WM_PID
is set by the application: right, that does make more sense! But it's not the X11 protocol, it's the relatively recent FreeDesktop specification.– Gilles
Jan 8 '11 at 12:26
In the ssh case, as far as the X server is concerned, this is a local connection from the sshd process. Though
_NET_WM_PID
seems to be set to the remote PID and WM_CLIENT_MACHINE
to the remote connection (tested with xterm).– Gilles
Jan 8 '11 at 12:26
In the ssh case, as far as the X server is concerned, this is a local connection from the sshd process. Though
_NET_WM_PID
seems to be set to the remote PID and WM_CLIENT_MACHINE
to the remote connection (tested with xterm).– Gilles
Jan 8 '11 at 12:26
add a comment |
I was able to use the xdotool
under Ubuntu 11.04 beta, but selectwindow
was not a valid command, I had to hack a script with:
$ while true; do sleep 1; xdotool getactivewindow; done
then watch the window ID go by while I selected the window I wanted, then decoded the responsible PID with:
$ xdotool getwindowpid <the-window-id>
add a comment |
I was able to use the xdotool
under Ubuntu 11.04 beta, but selectwindow
was not a valid command, I had to hack a script with:
$ while true; do sleep 1; xdotool getactivewindow; done
then watch the window ID go by while I selected the window I wanted, then decoded the responsible PID with:
$ xdotool getwindowpid <the-window-id>
add a comment |
I was able to use the xdotool
under Ubuntu 11.04 beta, but selectwindow
was not a valid command, I had to hack a script with:
$ while true; do sleep 1; xdotool getactivewindow; done
then watch the window ID go by while I selected the window I wanted, then decoded the responsible PID with:
$ xdotool getwindowpid <the-window-id>
I was able to use the xdotool
under Ubuntu 11.04 beta, but selectwindow
was not a valid command, I had to hack a script with:
$ while true; do sleep 1; xdotool getactivewindow; done
then watch the window ID go by while I selected the window I wanted, then decoded the responsible PID with:
$ xdotool getwindowpid <the-window-id>
edited May 26 '11 at 22:56
Michael Mrozek♦
61.2k29190211
61.2k29190211
answered Apr 17 '11 at 14:49
Jon BaileyJon Bailey
412
412
add a comment |
add a comment |
Thanks for contributing an answer to Unix & Linux Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f5478%2fwhat-process-created-this-x11-window%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Related: PID from window ID/name
– Gilles
Aug 29 '12 at 23:16