Когда приложение падает из-за несовместимой или отсутствующей библиотеки,
ldd полезен, но он показывает, как динамический загрузчик разрешает зависимости для бинаря, а не текущее состояние уже запущенного процесса.Если нужен точный ответ, что уже замаплено в память, используем
/proc.Сначала находим PID процесса:
pgrep -a python
Допустим, это 1234. Теперь смотрим, какие shared objects отображены в его адресное пространство:
grep '\.so' /proc/1234/maps
Что здесь важно:
/proc/<pid>/maps — карта памяти процесса; каждая строка — отдельный участок памяти; если в строке есть путь к .so, значит есть файловый маппинг этого объекта.Пример:
7f2c1a000000-7f2c1a200000 r-xp ... /usr/lib/x86_64-linux-gnu/libssl.so.1.1
Это означает, что в адресном пространстве процесса есть маппинг этой версии
libssl (и, с высокой вероятностью, она используется процессом).Если нужен список без дублей:
grep '\.so' /proc/1234/maps | awk '{print $6}' | sort -u
Практический кейс — конфликт версий после обновления: систему обновили, новая библиотека уже лежит на диске, а процесс всё ещё держит старую версию в памяти.
Проверить можно так:
ls -l /proc/1234/map_files/
Если у файла есть пометка (deleted), это сильный сигнал: файл на диске уже удалён или заменён, но процесс продолжает использовать старый
inode через существующий маппинг.🔥 Что важно помнить: изменения на диске не влияют на уже загруженные библиотеки в работающем процессе, после обновления библиотек сервисы обычно нужно перезапускать, доступ к
/proc/<pid> и особенно map_files может быть ограничен правами.🚪 Linux Ready | #практика