У меня есть процесс (dbus-daemon), который имеет много открытых соединений через сокеты 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-daemon на самом деле является сервером. Что в порядке. Но как я могу найти, какой процесс связан с ним - используя соединение, являющееся 36-м дескриптором файла в dbus-launcher? Пробовал lsof и даже greps на / proc / net / unix, но я не могу найти способ найти клиентский процесс.
Ответы:
Совсем недавно я наткнулся на похожую проблему. Я был потрясен, узнав, что есть случаи, когда это может быть невозможно. Я откопал комментарий от создателя lsof (Vic Abell), где он указал, что это сильно зависит от реализации сокетов Unix. Иногда так называемая «конечная точка» информация для сокета доступна, а иногда нет. К сожалению, это невозможно в Linux, как он указывает.
Если вы посмотрите на / proc / net / unix, то увидите, что (по крайней мере, в моей системе) он абсолютно прав. Я все еще в шоке, потому что я нахожу такую функцию важной при отслеживании проблем с сервером.
источник
/proc/net/unix
БУДЕТ сообщать вам целевой файл о случайной ссылке на сокет домена, из которой вы выкопали/proc/.../fd/
.Этот ответ только для Linux. Основываясь на ответе Unix & Linux Stack Exchange, я успешно определил другой конец сокета домена unix, используя структуры данных в ядре, доступ к которым осуществляется с помощью
gdb
и/proc/kcore
. Вам необходимо включить параметры ядраCONFIG_DEBUG_INFO
иCONFIG_PROC_KCORE
.Вы можете использовать
lsof
для получения адреса ядра сокета, который принимает форму указателя, например0xffff8803e256d9c0
. Это число на самом деле является адресом соответствующей структуры или типа памяти в ядреstruct unix_sock
. Эта структура имеет поле с именем,peer
которое указывает на другой конец сокета. Итак, командынапечатает адрес другого конца соединения. Вы можете получить выходные данные
lsof -U
для этого номера, чтобы определить номер процесса и дескриптора файла этого другого конца.Некоторые дистрибутивы предоставляют символы отладки ядра в виде отдельного пакета, который заменяет
vmlinux
файл в приведенной выше команде.источник
peer
члена вunix_sock
структуре. В моей системе x86_64 это смещение составляет 656 байт, так что я могу получить другой конец, используяp ((void**)0xffff8803e256d9c0)[0x52]
. Вам все еще нужноCONFIG_PROC_KCORE
, очевидно.На самом деле,
ss
изiproute2
(замена для netstat, ifconfig и т. Д.) Может показать эту информацию.Вот пример, показывающий сокет домена six-агента unix, к которому подключен
ssh
процесс:источник
Unix-сокетам обычно присваиваются номера в парах, и обычно они являются последовательными. Таким образом, пара для вас, вероятно, будет 1013410 +/- 1. Посмотрите, какой из этих двух существует, и догадайтесь на виновника.
источник
Я написал инструмент, который использует метод gdb от MvG для надежного получения информации о равноправных объектах сокета, символы отладки ядра не нужны.
Чтобы подключить процесс к данному сокету, передайте ему номер инода:
Чтобы выяснить, все ли процессы используются одновременно
netstat_unix
, он добавляет столбец к выводу netstat:Попробуйте,
netstat_unix --dump
если вам нужен вывод, который легко разобрать.См. Https://github.com/lemonsqueeze/unix_sockets_peers для деталей.
Для информации взломать inode + 1 / -1 не надежно. Он работает большую часть времени, но потерпит неудачу или (что еще хуже) вернет неправильный сокет, если вам не повезло.
источник
Отредактируйте ваш system.conf
В этом файле вы можете добавить больше материала для отладки.
Расположение файла:
/etc/dbus-1/system.conf
Источник: http://old.nabble.com/dbus-send-error-td29893862.html
Некоторые другие полезные вещи, касающиеся сокетов Unix
Самый простой способ выяснить, что происходит на шине, - запустить
dbus-monitor
программу, поставляемую с пакетом D-Bus.Также вы можете попытаться использовать
dbus-cleanup-sockets
для очистки оставшихся сокетов.Следующая команда покажет вам, сколько раз процесс подключен к сокетам dbus на основе
netstat
выходных данных:(проверено на Ubuntu)
Hardcore way: эта команда найдет вручную процессы из / proc и покажет, которые используют больше всего соединений (все типы сокетов):
Пример вывода:
(count, PID и следующая строка содержит информацию о процессе)
(проверено на Ubuntu)
Повеселись.
Смотрите также соответствующие статьи для справки:
источник