Ответ 1
ss -p
расскажет. (Если сокет не принадлежит самому ядру.)
Процесс в моей системе Linux, говорит мне strace, говорит о сокет, который имеет дескриптор файла 10. lsof говорит мне, что это unix-сокет с inode 11085, а netstat далее сообщает мне, что inode 11085 - и что он подключен.
Учитывая, что в этом процессе нет других потоков, в системе должен быть еще один процесс, связанный с другим концом этого сокета. Как узнать, что это такое?
Update:
Там некоторое освещение от автора lsof здесь. По сути, кажется, что Linux просто не предоставляет эту информацию.
ss -p
расскажет. (Если сокет не принадлежит самому ядру.)
Помогает ли netstat -p
?
Из Manpage:
-p,
--program Show the PID and name of the program to which each socket belongs.
Как насчет этого: grep 11085 /proc/net/unix
. Предполагая, что существует непустой путь, присутствующий в строке, с интересующим вас inode, grep
для этого пути в /proc/net/unix
, чтобы найти inode для другого конца соединения, затем используйте метод @efficientjelly для сопоставьте другой индекс inode с pid
.
Ключевым моментом здесь является тот факт, что каждый из двух подключенных сокетов будет иметь разные номера inode.
Похоже, если вы действительно в отчаянии, вы можете получить эту информацию непосредственно из памяти ядра Linux, используя некоторый отладчик ядра. С инструментом RHEL5 "сбой":
vmlinux
изображение (например, установить kernel-debuginfo
rpm или извлечь файл vmlinux
из этого числа оборотов в минуту)crash /path/to/vmlinux
net -s 12345
перечислены все сокеты для PID
12345UNIX:STREAM
) и обратите внимание на его значение SOCK
:
PID: 12345 TASK: e903d000 CPU: 0 COMMAND: "someapp"
FD SOCKET SOCK FAMILY:TYPE SOURCE-PORT DESTINATION-PORT
36 cadd0240 c8a64040 UNIX:STREAM
unix_sock struct
для этого сокета
unix_sock.peer.name
- это структура имени другого конца сокетаp *(*(*((struct unix_sock*)( (struct unix_sock*)0xc8a64040)->peer)).addr).name
Действительно печально, что эта информация напрямую не экспортируется в пользовательское пространство.
Я заметил, что:
Инод fd
, который называется connect()
на стороне клиента, всегда точно больше, чем тот, который вы получили от вызова accept()
на стороне сервера.
Пример вывода из моей проги:
client_fd=4
/proc/4436/fd/4
inode=3072
is socket
node: 3072 socket: /tmp/unix.socket
f0be8960: 00000003 00000000 00000000 0001 03 3072 /tmp/unix.socket
/proc/9293/fd/43
fd:43
inode=3073
is socket
node: 3073 socket:
f0be81e0: 00000003 00000000 00000000 0001 03 3073
Связанный путь не отображается в /proc/net/unix
, хотя.
YMMV и я не исследовали основную механику.
Я написал инструмент который использует метод gdb для надежного получения сокета информация о свертке, символы отладки ядра не нужны.
Чтобы связать процесс с данным сокетом, передайте ему номер inode:
# socket_peer 11085
3703 thunderbird
Чтобы узнать, что все процессы сразу используют netstat_unix
, он добавляет столбец к выводу netstat:
# netstat_unix
Proto RefCnt Flags Type State I-Node PID/Program name Peer PID/Program name Path
unix 3 [ ] STREAM CONNECTED 6825 982/Xorg 1497/compiz /tmp/.X11-unix/X0
unix 3 [ ] STREAM CONNECTED 6824 1497/compiz 982/Xorg
unix 3 [ ] SEQPACKET CONNECTED 207142 3770/chromium-brows 17783/UMA-Session-R
unix 3 [ ] STREAM CONNECTED 204903 1523/pulseaudio 3703/thunderbird
unix 3 [ ] STREAM CONNECTED 204902 3703/thunderbird 1523/pulseaudio
unix 3 [ ] STREAM CONNECTED 204666 1523/pulseaudio 3703/thunderbird
...
Попробуйте netstat_unix --dump
, если вам нужен вывод, который легко разобрать.
Подробнее см. https://github.com/lemonsqueeze/unix_sockets_peers.
Для справки inode + 1/-1 hack не является надежным. Он работает большую часть времени, но не сработает или (хуже) вернет неправильный сокет, если вам не повезло.
Если по какой-то причине вам не повезло с соответствующими параметрами lsof и netstat, вы также можете сделать следующее:
find /proc -lname '*11085*' 2> /dev/null
lsof | grep 11085
lsof должен выполняться как root.
Я экспериментировал с lsof в своей Linux-системе, а lsof -U
показывает, что все числа под столбцом NODE уникальны.