Frank Cusack <fcusackfcusack.com> writes:
>I'm stracing a process which shows that it is reading/writing from/to fd 3.
>lsof shows that fd 3 is a unix domain socket.> kdesktop_ 9665 marc 3u unix 0xe0d32980 884489 socket>How do I find the other end of this socket? Grep'ing the device
>(0xe0d32980) or the inode (884489) out of the system-wide lsof output
>yields only the line above.The lsof part of the question might more appropriately have been>netstat doesn't give any help either.
directed to me, the lsof author, or to the lsof-l mailing list.
As it is there isn't enough detail to form a precise answer, because
the UNIX dialect on which lsof is being used is unknown, and the lsof
revision is unknown.
Those details matter because dialect UNIX domain socket implementation
and internal details differ significantly, and because lsof revisions
In the general case, an imprecise answer to your question is that, if
the UNIX dialect's UNIX domain socket structures indicate the other
endpoint of an open UNIX domain socket file, lsof will report its UNIX
protocol control block address in the NAME column, and that same
address will appear in the DEVICE column of endpoint's open file.
For example, on 32 bit AIX 5.1 this might be reported as:
COMMAND PID USER FD TYPE DEVICE ... NAME
rmcd 11138 root 11u unix 0x70703200 ... ->0x70703000
IBM.ERrmd 18836 root 6u unix 0x70703000 ... /var/ct/IW/soc/mc/RMIBM.ERRM.0
The above example is interesting for another reason -- the IBM.ERrmd
process has bound the /var/ct/IW/soc/mc/RMIBM.ERRM.0 path to the UNIX
domain socket, while the rmcd process has not.
Lsof reports UNIX domain socket information differently on other UNIX
dialects. On Linux, for example, where lsof must use /proc/net/unix,
all UNIX domain sockets have a bound path, but no endpoint information.
Often there is no bound path. That often makes it impossible to
determine the other endpoint, but it is a result of the Linux /proc
file system implementation.
Vic Abell, lsof author, <abepurdue.edu>