Вопрос: Как найти другой конец соединения сокета unix?


У меня есть процесс (dbus-демон), который имеет много открытых соединений по UNIX-сокетам. Одним из этих соединений является fd # 36:

=$ ps uw -p 23284
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
depesz   23284  0.0  0.0  24680  1772 ?        Ss   15:25   0:00 /bin/dbus-daemon --fork --print-pid 5 --print-address 7 --session

=$ ls -l /proc/23284/fd/36 
lrwx------ 1 depesz depesz 64 2011-03-28 15:32 /proc/23284/fd/36 -> socket:[1013410]

=$ netstat -nxp | grep 1013410
(Not all processes could be identified, non-owned process info
 will not be shown, you would have to be root to see it all.)
unix  3      [ ]         STREAM     CONNECTED     1013410  23284/dbus-daemon   @/tmp/dbus-3XDU4PYEzD

=$ netstat -nxp | grep dbus-3XDU4PYEzD
unix  3      [ ]         STREAM     CONNECTED     1013953  23284/dbus-daemon   @/tmp/dbus-3XDU4PYEzD
unix  3      [ ]         STREAM     CONNECTED     1013825  23284/dbus-daemon   @/tmp/dbus-3XDU4PYEzD
unix  3      [ ]         STREAM     CONNECTED     1013726  23284/dbus-daemon   @/tmp/dbus-3XDU4PYEzD
unix  3      [ ]         STREAM     CONNECTED     1013471  23284/dbus-daemon   @/tmp/dbus-3XDU4PYEzD
unix  3      [ ]         STREAM     CONNECTED     1013410  23284/dbus-daemon   @/tmp/dbus-3XDU4PYEzD
unix  3      [ ]         STREAM     CONNECTED     1012325  23284/dbus-daemon   @/tmp/dbus-3XDU4PYEzD
unix  3      [ ]         STREAM     CONNECTED     1012302  23284/dbus-daemon   @/tmp/dbus-3XDU4PYEzD
unix  3      [ ]         STREAM     CONNECTED     1012289  23284/dbus-daemon   @/tmp/dbus-3XDU4PYEzD
unix  3      [ ]         STREAM     CONNECTED     1012151  23284/dbus-daemon   @/tmp/dbus-3XDU4PYEzD
unix  3      [ ]         STREAM     CONNECTED     1011957  23284/dbus-daemon   @/tmp/dbus-3XDU4PYEzD
unix  3      [ ]         STREAM     CONNECTED     1011937  23284/dbus-daemon   @/tmp/dbus-3XDU4PYEzD
unix  3      [ ]         STREAM     CONNECTED     1011900  23284/dbus-daemon   @/tmp/dbus-3XDU4PYEzD
unix  3      [ ]         STREAM     CONNECTED     1011775  23284/dbus-daemon   @/tmp/dbus-3XDU4PYEzD
unix  3      [ ]         STREAM     CONNECTED     1011771  23284/dbus-daemon   @/tmp/dbus-3XDU4PYEzD
unix  3      [ ]         STREAM     CONNECTED     1011769  23284/dbus-daemon   @/tmp/dbus-3XDU4PYEzD
unix  3      [ ]         STREAM     CONNECTED     1011766  23284/dbus-daemon   @/tmp/dbus-3XDU4PYEzD
unix  3      [ ]         STREAM     CONNECTED     1011663  23284/dbus-daemon   @/tmp/dbus-3XDU4PYEzD
unix  3      [ ]         STREAM     CONNECTED     1011635  23284/dbus-daemon   @/tmp/dbus-3XDU4PYEzD
unix  3      [ ]         STREAM     CONNECTED     1011627  23284/dbus-daemon   @/tmp/dbus-3XDU4PYEzD
unix  3      [ ]         STREAM     CONNECTED     1011540  23284/dbus-daemon   @/tmp/dbus-3XDU4PYEzD
unix  3      [ ]         STREAM     CONNECTED     1011480  23284/dbus-daemon   @/tmp/dbus-3XDU4PYEzD
unix  3      [ ]         STREAM     CONNECTED     1011349  23284/dbus-daemon   @/tmp/dbus-3XDU4PYEzD
unix  3      [ ]         STREAM     CONNECTED     1011312  23284/dbus-daemon   @/tmp/dbus-3XDU4PYEzD
unix  3      [ ]         STREAM     CONNECTED     1011284  23284/dbus-daemon   @/tmp/dbus-3XDU4PYEzD
unix  3      [ ]         STREAM     CONNECTED     1011250  23284/dbus-daemon   @/tmp/dbus-3XDU4PYEzD
unix  3      [ ]         STREAM     CONNECTED     1011231  23284/dbus-daemon   @/tmp/dbus-3XDU4PYEzD
unix  3      [ ]         STREAM     CONNECTED     1011155  23284/dbus-daemon   @/tmp/dbus-3XDU4PYEzD
unix  3      [ ]         STREAM     CONNECTED     1011061  23284/dbus-daemon   @/tmp/dbus-3XDU4PYEzD
unix  3      [ ]         STREAM     CONNECTED     1011049  23284/dbus-daemon   @/tmp/dbus-3XDU4PYEzD
unix  3      [ ]         STREAM     CONNECTED     1011035  23284/dbus-daemon   @/tmp/dbus-3XDU4PYEzD
unix  3      [ ]         STREAM     CONNECTED     1011013  23284/dbus-daemon   @/tmp/dbus-3XDU4PYEzD
unix  3      [ ]         STREAM     CONNECTED     1010961  23284/dbus-daemon   @/tmp/dbus-3XDU4PYEzD
unix  3      [ ]         STREAM     CONNECTED     1010945  23284/dbus-daemon   @/tmp/dbus-3XDU4PYEzD

Основываясь на числовых соединениях, я предполагаю, что dbus-демон фактически является сервером. Это нормально. Но как я могу найти, какой процесс связан с ним - используя соединение, которое является 36-м дескриптором файла в dbus-пусковой установке? Пробовал lsof и даже greps on / proc / net / unix, но я не могу найти способ найти процесс клиента.


38
2018-03-28 13:35


Источник


На это отвечает U & L: У кого есть другой конец этого гнездового гнезда unix? - sch


Ответы:


Совсем недавно я наткнулся на аналогичную проблему. Я был потрясен, узнав, что есть случаи, когда это может быть невозможно. Я выкопал комментарий от создателя lsof (Vic Abell), где он указал, что это сильно зависит от реализации сокета unix. Иногда доступна так называемая «конечная точка» для сокета, а иногда нет. К сожалению, это невозможно в Linux, как он указывает.

Например, в Linux, где lsof должен   use / proc / net / unix, весь домен UNIX   сокеты имеют связанный путь, но нет   информация о конечной точке. Часто существует   нет связанного пути. Это часто делает это   невозможно определить другое   конечной точки, но это результат   Файловая система Linux / proc   реализация.

Если вы посмотрите на / proc / net / unix, вы можете сами убедиться, что (по крайней мере, в моей системе) он абсолютно прав. Я все еще шокирован, потому что я нахожу такую ​​особенность необходимой при отслеживании проблем сервера.


23
2018-06-03 09:03



Справка: groups.google.com/forum/#!topic/comp.unix.admin/iZLsq5dHdyI - estani
Обратите внимание, что /proc/net/unix WILL сообщит вам файл цели со ссылкой на случайный домен, который вы выкопали из /proc/.../fd/, - i336_


Этот ответ предназначен только для Linux. Основано на ответ из Unix & Linux Stack Exchange, я успешно идентифицированы на другом конце сокета домена unix, использующем встроенные структуры данных, доступ к которым осуществляется с помощью gdb а также /proc/kcore, Вам необходимо включить CONFIG_DEBUG_INFO а также CONFIG_PROC_KCORE Параметры ядра.

Вы можете использовать lsof для получения адреса ядра сокета, который принимает форму указателя, например. 0xffff8803e256d9c0, Это число фактически является адресом соответствующей внутриядерной структуры памяти или типа struct unix_sock, Эта структура имеет поле, называемое peer который указывает на другой конец гнезда. Таким образом, команды

# gdb /usr/src/linux/vmlinux /proc/kcore
(gdb) p ((struct unix_sock*)0xffff8803e256d9c0)->peer

будет печатать адрес другого конца соединения. Вы можете выполнить grep вывод lsof -U для этого числа, чтобы идентифицировать номер процесса и файла дескриптора этого другого конца.

Некоторые дистрибутивы, похоже, предоставляют символы отладки ядра в виде отдельного пакета, который заменил бы vmlinux файл в приведенной выше команде.


23
2017-08-15 20:31



Это выглядит интересно, но требование перекомпилировать ядро ​​кажется излишним. Я думаю, что, возможно, это можно было бы сделать без ручного ядра и без использования gdb, просто взглянув на значения в kcore и выполнив некоторое «ручное» декодирование значений.
@depesz, все, что вам нужно знать, это смещение peer член в unix_sock состав. В моей системе x86_64 это смещение составляет 656 байт, поэтому я мог бы получить этот другой конец, используя p ((void**)0xffff8803e256d9c0)[0x52], Вам все еще нужно CONFIG_PROC_KCORE, очевидно. - MvG


Разъемы Unix как правило назначаются числа парами и обычно являются последовательными. Таким образом, пара для вас, вероятно, будет 1013410 +/- 1. Посмотрите, какая из этих двух существует, и догадайтесь о виновнике.


9
2018-01-26 22:13





На самом деле, ss из iproute2 (замена netstat, ifconfig и т. д.) может показать эту информацию.

Ниже приведен пример, показывающий сокет домена unix ssh-agent, к которому ssh процесс подключился:

$ sudo ss -a --unix -p
Netid  State      Recv-Q Send-Q Local                             Address:Port          Peer    Address:Port
u_str  ESTAB      0      0      /tmp/ssh-XxnMh2MdLBxo/agent.27402 651026                *       651642                users:(("ssh-agent",pid=27403,fd=4)
u_str  ESTAB      0      0       *                                651642                *       651026                users:(("ssh",pid=2019,fd=4))

7
2018-03-06 13:01



Хм. Интересно ... Я пропустил, что столбцы «Адрес: Порт» могут быть сопоставлены, хотя столбец «Peer» абсолютно бесполезен для сокетов домена unix. - SamB


Я написал инструмент который использует MvG метод gdb чтобы надежно получить информацию о сокетном ядре, символы отладки ядра не нужны.

Чтобы связать процесс с данным сокетом, передайте ему номер inode:

# socket_peer 1013410
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 взломать не является надежным. Он работает большую часть времени, но сбой или (что еще хуже) возвращают неправильный сокет, если вам не повезло.


6
2017-11-14 14:44



Очень полезно, спасибо за скрипты! - Tonin


Отредактируйте файл system.conf

В этом файле вы можете добавить больше вещей для целей отладки.

Расположение файла: /etc/dbus-1/system.conf

Для целей отладки вы можете отредактировать файл system.conf, чтобы разрешить   подслушивание:

  1. замените раздел политики на:

    <policy context="default">

    <!-- Allow everything to be sent --> 

    <allow send_destination="*" eavesdrop="true"/> 

    <!-- Allow everything to be received --> 

    <allow eavesdrop="true"/> 

    <!-- Allow anyone to own anything --> 

    <allow own="*"/> 

    <!-- XXX: Allow all users to connect --> 

    <allow user="*"/> </policy> 

  2. Удалите строку includedir: system.d

    <includedir>system.d</includedir> 

Источник: http://old.nabble.com/dbus-send-error-td29893862.html


Некоторые другие полезные сведения о UNIX-сокетах

Самый простой способ выяснить, что происходит на шине, - запустить dbus-monitor программа, которая поставляется с пакетом D-Bus

Также вы можете попробовать использовать dbus-cleanup-sockets для очистки оставшихся гнезд.

Следующая команда покажет вам, какой процесс подключен, сколько раз к разъемам dbus на основе netstat вывод:

sudo netstat -nap | grep dbus | grep CONNECTED | awk '{print $8}' | sort | uniq -c

(проверено на Ubuntu)

Hardcore way: эта команда найдет вручную процессы из / proc и show, которые используют большинство соединений (все типы сокетов):

ls -lR */fd/* | grep socket | sed -r "s@([0-9{1}]+)/fd/@_\1_@g" | awk -F_ '{print $2}' | uniq -c | sort -n | awk '{print $1" "$2; print system("ps "$2"|tail -n1")}'

Пример вывода:

(счетчик, PID и следующая строка содержат сведения о процессе)

25 3732
 3732 ?        Ss     0:38 /usr/bin/wineserver
89 1970
 1970 ?        Ss     0:02 //bin/dbus-daemon --fork --print-pid 5 --print-address 7 --session

(проверено на Ubuntu)

Повеселись.


См. Также соответствующие статьи для справки:


1
2017-09-19 16:25