Найдите создателя конкретного Unix-сокета.

Содержание

Вопрос или проблема
Ответ или решение
Использование системных инструментов
Ограничения
Возможные способы выяснения создателя сокета
Заключение

Вопрос или проблема

Мне трудно выяснить, какой именно процесс создал Unix-сокет.

Я читал несколько постов об этом, таких как использование lsof -nl (что обычно показывает pid процесса, который слушает Unix-сокет), использование netstat -tulpen, который не показывает сокет, который я ищу, и т.д.

В основном, я хочу, чтобы процесс gnome-keyring слушал некоторый Unix-сокет (/run/user/1000/keyring-.../ssh), но какой именно процесс создал этот сокет? Есть ли команда, которая помогла бы мне выяснить, какой именно процесс (я мог бы использовать имя Unix-сокета, если это было бы полезно) создал сокет? Спасибо.

П.С.
Не должно ли эта информация храниться где-то в /proc/pid/...?

Насколько мне известно, вы не можете это узнать.

Простая команда lsof /run/user/1000/keyring-.../ssh выведет список процессов, которые в данный момент имеют открытый файл (или конвейер).

Если процесс создал файл и, следовательно, завершил свою работу, любая информация о нем теряется.

Ответ или решение

Чтобы определить, какой процесс создал определенный Unix-сокет, необходимо учитывать ряд аспектов, поскольку эта информация не всегда доступна по умолчанию. Unix-сокеты, в частности, создаются процессами для межпроцессного взаимодействия, и когда процесс завершает свою работу, информация о создавшем его процессе фактически теряется.

Использование системных инструментов

Наиболее популярными инструментами для проверки открытых сокетов являются lsof и netstat. Как вы упомянули, команда lsof -nl может показать, какие процессы используют конкретный сокет, но не обязательно укажет, какой процесс его создал, особенно если этот процесс уже завершил свою работу.

Команда lsof

Чтобы узнать, какой процесс в настоящее время использует сокет, вы можете выполнить команду:
```
lsof /run/user/1000/keyring-.../ssh
```
Эта команда предоставит вам список процессов, которые открыли указанный сокет. Однако она не даст информацию о том, какой процесс его создал, если тот уже завершился.
Команда netstat

Как вы отметили, команда netstat -tulpen может не показывать нужный сокет, поскольку она больше предназначена для сетевых сокетов.
Просмотр каталога /proc

Действительно, в каталоге /proc содержится информация о процессах, но она ограничена только активными процессами. Вы можете просматривать файлы в /proc/<pid>/, но если процесс завершился, такой информации не будет.

Ограничения

К сожалению, если процесс, создавший сокет, завершился, стандартные инструменты не предоставляют информацию о его идентификаторе. Когда процесс создает сокет, а затем завершает работу, его идентификатор (PID) исчезает из /proc. Таким образом, вы не сможете получить данные о создавшем процессе просто через запрос к системе.

Возможные способы выяснения создателя сокета

Отладочные инструменты: Если вы хотите получить более детальную информацию о создании сокетов, вам могут помочь инструменты для отладки, такие как strace. Но это требует предварительного запуска процесса в режиме отслеживания.
Мониторинг системы: Вы можете запускать мониторинг системных вызовов для процессов, которые вас интересуют. Это может быть сделано с помощью auditd или SystemTap, что позволит вам регистрировать создание сокетов прямо во время работы системы.
Логи приложений: Наконец, многие приложения ведут логи, где могут содержаться записи о создании сокетов. Проверьте документацию соответствующего приложения или его настройки для анализа логов.

Заключение

К сожалению, в стандартных инструментах UNIX/Linux нет простого способа определить, какой процесс создал сокет, когда он уже завершился. Однако, проведя мониторинг активных процессов и используя некоторую диагностику, а также логи, можно попробовать выяснить это в реальном времени или через анализ предыдущей активности системы.

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