Note: I now maintain a lsof wrapper that combines both approaches described here and also adds information for peers of loopback TCP connections at https://github.com/stephane-chazelas/misc-scripts/blob/master/lsofc

Linux-3.3 and above.

On Linux, since kernel version 3.3 (and provided the UNIX_DIAG feature is built in the kernel), the peer of a given unix domain socket (includes socketpairs) can be obtained using a new netlink based API.

lsof since version 4.89 can make use of that API:

lsof +E -aUc Xorg

Will list all the Unix domain sockets that have a process whose name starts with Xorg at either end in a format similar to:

Xorg 2777 root 56u unix 0xffff8802419a7c00 0t0 34036 @/tmp/.X11-unix/X0 type=STREAM ->INO=33273 4120,xterm,3u

If your version of lsof is too old, there are a few more options.

The ss utility (from iproute2 ) makes use of that same API to retrieve and display information on the list of unix domain sockets on the system including peer information.

The sockets are identified by their inode number. Note that it's not related to the filesystem inode of the socket file.

For instance in:

$ ss -x [...] u_str ESTAB 0 0 @/tmp/.X11-unix/X0 3435997 * 3435996

it says that socket 3435997 (that was bound to the ABSTRACT socket /tmp/.X11-unix/X0 ) is connected with socket 3435996. The -p option can tell you which process(es) have that socket open. It does that by doing some readlink s on /proc/$pid/fd/* , so it can only do that on processes you own (unless you're root ). For instance here:

$ sudo ss -xp [...] u_str ESTAB 0 0 @/tmp/.X11-unix/X0 3435997 * 3435996 users:(("Xorg",pid=3080,fd=83)) [...] $ sudo ls -l /proc/3080/fd/23 lrwx------ 1 root root 64 Mar 12 16:34 /proc/3080/fd/83 -> socket:[3435997]

To find out what process(es) has 3435996, you can look up its own entry in the output of ss -xp :

$ ss -xp | awk '$6 == 3435996' u_str ESTAB 0 0 * 3435996 * 3435997 users:(("xterm",pid=29215,fd=3))

You could also use this script as a wrapper around lsof to easily show the relevant information there:

#! /usr/bin/perl # lsof wrapper to add peer information for unix domain socket. # Needs Linux 3.3 or above and CONFIG_UNIX_DIAG enabled. # retrieve peer and direction information from ss my (%peer, %dir); open SS, '-|', 'ss', '-nexa'; while (<SS>) { if (/\s(\d+)\s+\*\s+(\d+) ([<-]-[->])$/) { $peer{$1} = $2; $dir{$1} = $3; } } close SS; # Now get info about processes tied to sockets using lsof my (%fields, %proc); open LSOF, '-|', 'lsof', '-nPUFpcfin'; while (<LSOF>) { if (/(.)(.*)/) { $fields{$1} = $2; if ($1 eq 'n') { $proc{$fields{i}}->{"$fields{c},$fields{p}" . ($fields{n} =~ m{^([@/].*?)( type=\w+)?$} ? ",$1" : "")} = ""; } } } close LSOF; # and finally process the lsof output open LSOF, '-|', 'lsof', @ARGV; while (<LSOF>) { chomp; if (/\sunix\s+\S+\s+\S+\s+(\d+)\s/) { my $peer = $peer{$1}; if (defined($peer)) { $_ .= $peer ? " ${dir{$1}} $peer\[" . (join("|", keys%{$proc{$peer}})||"?") . "]" : "[LISTENING]"; } } print "$_

"; } close LSOF or exit(1);

For example:

$ sudo that-lsof-wrapper -ad3 -p 29215 COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME xterm 29215 stephane 3u unix 0xffff8800a07da4c0 0t0 3435996 type=STREAM <-> 3435997[Xorg,3080,@/tmp/.X11-unix/X0]

Before linux-3.3

The old Linux API to retrieve unix socket information is via the /proc/net/unix text file. It lists all the Unix domain sockets (including socketpairs). The first field in there (if not hidden to non-superusers with the kernel.kptr_restrict sysctl parameter) as already explained by @Totor contains the kernel address of a unix_sock structure that contains a peer field pointing to the corresponding peer unix_sock . It's also what lsof outputs for the DEVICE column on a Unix socket.

Now getting the value of that peer field means being able to read kernel memory and know the offset of that peer field with regards to the unix_sock address.

Several gdb -based and systemtap -based solutions have already been given but they require gdb / systemtap and Linux kernel debug symbols for the running kernel being installed which is generally not the case on production systems.

Hardcoding the offset is not really an option as that varies with kernel version.

Now we can use a heuristic approach at determining the offset: have our tool create a dummy socketpair (then we know the address of both peers), and search for the address of the peer around the memory at the other end to determine the offset.

Here is a proof-of-concept script that does just that using perl (successfully tested with kernel 2.4.27 and 2.6.32 on i386 and 3.13 and 3.16 on amd64). Like above, it works as a wrapper around lsof :

For example:

$ that-lsof-wrapper -aUc nm-applet COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME nm-applet 4183 stephane 4u unix 0xffff8800a055eb40 0t0 36888 type=STREAM -> 0xffff8800a055e7c0[dbus-daemon,4190,@/tmp/dbus-AiBCXOnuP6] nm-applet 4183 stephane 7u unix 0xffff8800a055e440 0t0 36890 type=STREAM -> 0xffff8800a055e0c0[Xorg,3080,@/tmp/.X11-unix/X0] nm-applet 4183 stephane 8u unix 0xffff8800a05c1040 0t0 36201 type=STREAM -> 0xffff8800a05c13c0[dbus-daemon,4118,@/tmp/dbus-yxxNr1NkYC] nm-applet 4183 stephane 11u unix 0xffff8800a055d080 0t0 36219 type=STREAM -> 0xffff8800a055d400[dbus-daemon,4118,@/tmp/dbus-yxxNr1NkYC] nm-applet 4183 stephane 12u unix 0xffff88022e0dfb80 0t0 36221 type=STREAM -> 0xffff88022e0df800[dbus-daemon,2268,/var/run/dbus/system_bus_socket] nm-applet 4183 stephane 13u unix 0xffff88022e0f80c0 0t0 37025 type=STREAM -> 0xffff88022e29ec00[dbus-daemon,2268,/var/run/dbus/system_bus_socket]

Here's the script: