Как использовать lsof в Linux: подробное руководство с примерами

Быстрые ссылки

• Что такое lsof?
• Пример: базовый вывод lsof
• Пример: использование lsof с kill
• Практические советы и альтернативы
• Чек-листы и контрольные вопросы
• Заключение

Что такое lsof?

Команда lsof (list open files) нативно доступна в большинстве распределений Linux и сообщает список открытых файлов и связанных с ними процессов. В Unix-подобных системах «всё — файл»: сокеты, файлы, устройства и каталоги представлены в виде файловой сущности. lsof выводит информацию по каждому открытому файлу — какой процесс держит файл, каким образом он открыт, идентификаторы и т. д.

Определение: lsof — инструмент для диагностики открытых файлов и блокировок, полезный при отладке зависших приложений и освобождении ресурсов.

Важно: запускать lsof без привилегий может давать неполный вывод. Используйте sudo или выполните команду от root, если нужен полный список.

Примеры для получения root-доступа в терминале:

sudo su

или

su

или запуск конкретной команды с sudo:

sudo lsof

Пример: базовый вывод lsof

Запустим lsof и покажем первые 10 строк:

sudo su

lsof | head -n10

Кратко о колонках, которые вы увидите в типичном выводе lsof:

• COMMAND — команда/бинарник, который держит открытый файл.
• PID — идентификатор процесса. Часто используется для управления процессом.
• TID — идентификатор потока (если поддерживается ОС). Пустое поле обычно означает процесс, не поток.
• TASKCMD — имя команды задачи; видимо, для потоков/тасков.
• USER — пользователь, от которого запущен процесс.
• FD — файловый дескриптор: либо число (например, 102), либо метка вроде cwd, txt, mem, etc.; буквы после числа указывают режим доступа (r, w, u).
• TYPE — тип ресурса (REG — обычный файл, DIR — директория, CHR — символьное устройство, IPv4/IPv6 для сетевых сокетов и т. п.).
• DEVICE — номера устройства (major,minor) для локальных файлов.
• SIZE/OFF — размер файла или смещение в байтах.
• NODE — inode или идентификатор ноды; для сетевых соединений тут будут упоминания TCP/UDP и т. п.
• NAME — путь к файлу или дополнительная информация (например, адрес сокета).

Пояснение FD в двух строках: если вы видите “cwd” — это текущая рабочая директория процесса; если отображается число с буквой, например “13w” — это 13-й открытый файл процесса в режиме записи.

Совет: полная документация по строкам FD и прочим полям доступна в man lsof: откройте man lsof, введите / FD (три пробела после слеша перед FD) и нажмите Enter, чтобы перейти к разделу про FD.

Пример: использование lsof с kill

Зачастую нужно найти процесс, который держит конкретный файл или директорию, и завершить его. Ниже — общая цепочка команд для поиска PID по строке в выводе и завершения процессов:

lsof | grep 'some_file_descriptor' | awk '{print $2}' | xargs -I{} kill -9 {}

Разбор шагов:

• lsof — полный список открытых файлов.
• grep ‘some_file_descriptor’ — фильтрация по интересующей строке (например, по имени каталога или файлу).
• awk ‘{print $2}’ — извлекает вторую колонку (PID).
• xargs -I{} kill -9 {} — выполняет kill -9 для каждого переданного PID.

Важно: kill -9 завершает процесс без корректного завершения (SIGKILL). Используйте его только когда другие, более мягкие сигналы не сработали.

Практический пример с test.sh

Предположим, в /tmp создан скрипт test.sh со следующим содержимым:

rm -Rf workspace

mkdir workspace

cd workspace

sleep 36000

Скрипт создаёт директорию /tmp/workspace, переходит в неё и засыпает на 10 часов. Это держит cwd (current working directory) открытым — процесс будет удерживать дескриптор директории.

Запустив скрипт в одном терминале (например, через bash test.sh &), а затем выполнив lsof во втором, вы увидите записи, связанные с /tmp/workspace: и для test.sh, и для дочернего процесса sleep.

Пример изображения работы скрипта:

Для завершения всех процессов, удерживающих директорию workspace, можно выполнить:

lsof | grep "workspace" | grep -v "PID" | awk '{print $2}' | xargs -I{} kill -9 {}

Подробности:

• grep -v “PID” исключает заголовок, иначе awk может передать строку “PID” в kill.
• Альтернативы: вместо kill -9 сначала попробуйте kill -15 (SIGTERM), затем kill -9 только если процесс не завершается.

Практические советы и шаблоны команд

Шпаргалка часто используемых вариантов lsof:

• Показать все открытые файлы процесса с PID 1234:

lsof -p 1234

• Найти процессы, которые слушают конкретный TCP-порт (например, 80):

lsof -iTCP:80 -sTCP:LISTEN

• Найти процессы конкретного пользователя:

lsof -u alice

• Показать открытые файлы для конкретного файла на диске:

lsof /var/log/syslog

• Показать сетевые подключения процесса:

lsof -i -a -p 1234

• Форматированный вывод с указанием столбцов (удобно для парсинга):

lsof -F pcufn

Где флаги в -F означают: p — PID, c — COMMAND, u — USER, f — FD, n — NAME.

Когда lsof может не помочь

• Ограниченные привилегии: без root вы не увидите строки для процессов других пользователей или системных служб.
• Виртуальные/контейнерные окружения: внутри контейнера lsof покажет только процессы и ресурсы, видимые в контейнере. Для хоста используйте nsenter или запускайте lsof на хосте.
• Файлы, удалённые (unlink) но ещё открытые: lsof покажет такие файлы с пометкой (deleted); это полезно, но может сбивать с толку, если вы ожидаете увидеть файл по пути.
• Высокая нагрузка и быстрый churn процессов: между вызовами lsof и kill PID может измениться — PID уже не существует или перешло к другому процессу.

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

• fuser — утилита для вывода PID процессов, использующих файл или файловую систему; позволяет отправлять сигналы, аналогично lsof.
• ss/netstat — для сетевых соединений иногда удобнее ss, особенно для отображения состояния сокетов.
• auditd — если нужна длительная трассировка открытия файлов и событий безопасности.
• strace/ltrace — для отладки конкретного процесса и отслеживания вызовов open/close.

Модель мышления: как подходить к проблеме держания файла

1. Сформулируйте симптом: «Файл/каталог занят», «не могу размонтировать», «лог продолжает расти».
2. Идентифицируйте ресурс: точный путь или порт/сокет.
3. Найдите процессы с помощью lsof или fuser.
4. Попытайтесь мягко завершить процесс (kill -15). Подождите и проверьте.
5. Если нужно немедленное действие и вы уверены — kill -9.
6. Проанализируйте причину: баг приложения, неправильная обработка сигналов, демонизация, многопоточность.

Чек-листы по ролям

Администратор:

• Убедиться, что у вас есть root-доступ или sudo.
• Проверить, какой сервис использует файл: lsof -nP -iTCP:port или lsof /path.
• Попытаться graceful restart сервиса через systemctl restart service.
• Если необходимо, завершить процессы по PID.
• Проверить логи приложения после рестарта.

Разработчик:

• Добавить обработку сигналов в приложение (SIGTERM).
• Закрывать файловые дескрипторы при завершении.
• Добавить логирование открытия/закрытия файлов при отладке.

SRE/операции:

• Автоматизировать проверку открытых дескрипторов в мониторинге.
• Определить пороги и алерты на высокий FD count или невозможность монтирования томов.

Безопасность и осторожность

• Не запускайте kill -9 по автоматике без проверки — можно завершить важный системный процесс.
• Убедитесь, что PID, который вы собираетесь убить, действительно соответствует процессу, держащему ресурс. Используйте lsof -p PID или ps -p PID -o pid,cmd.
• В контейнерах контроль PID namespace важен: PID 1 внутри контейнера — это часто управляющий процесс контейнера.

Критерии приёмки

• Можно безопасно завершить зависший процесс без нарушения других сервисов.
• После завершения процесса ресурс освобождён (lsof больше не возвращает записи для этого пути).
• Журналы после рестарта не содержат повторяющихся ошибок, указывающих на ресурсную утечку.

Шаблон — шаги восстановления при блокировке директории

1. Определить путь, который нужно освободить.
2. Найти процессы: lsof | grep “/path/to/dir”.
3. Отфильтровать заголовок: grep -v “PID”.
4. Извлечь PID и попытаться kill -15.
5. Подождать 5–10 с, проверить статус.
6. Если процесс не завершился, kill -9.
7. Проверить систему и логи на причину.

Частые ошибки и как их избежать

• Ошибка: убить PID, который перешёл к другому процессу между моментами вызова команд. Решение: перед kill выполните ps -p -o pid,cmd чтобы убедиться в правильности.

• Ошибка: использование kill -9 как первой меры. Решение: применять SIGTERM сначала и логирование перед принудительным завершением.

• Ошибка: запуск lsof без sudo и недополучение информации. Решение: запускать sudo lsof или работать от root при диагностике системы.

Краткий глоссарий (1 строка на термин)

• PID — идентификатор процесса.
• FD — файловый дескриптор; число или специальная метка (cwd, txt).
• cwd — текущая рабочая директория процесса.
• inode — индексный узел файла на файловой системе.
• SIGTERM (15) — корректный запрос на завершение процесса.
• SIGKILL (9) — немедленное убийство процесса без обработки.

Дополнительные примеры команд и сценариев

1. Найти процессы, которые удерживают удалённые, но всё ещё открытые файлы:

lsof | grep '(deleted)'

2. Найти все файлы, открытые конкретным сервисом systemd (пример: nginx):

lsof -c nginx

3. Показать все открытые сетевые соединения и соответствующие PID:

lsof -i -P -n

4. Перенаправить вывод lsof в CSV-подобный формат для дальнейшего анализа:

lsof -Fpcufn | awk 'BEGIN{FS="\n";RS=""} {print $0}'

(Это базовый пример — под вашу задачу можно подобрать более строгий парсер.)

Заключение

lsof — универсальный инструмент для диагностики открытых файлов и сокетов в Linux. Он особенно полезен при размонтировании томов, отладке зависших скриптов и поиске процессов, удерживающих ресурсы. В сочетании с grep, awk и xargs lsof позволяет быстро находить PID процессов и управлять ими, но требуются осторожность и проверка контекста перед принудительным завершением.

Важно: всегда начинайте с мягких мер (SIGTERM), логируйте действия и анализируйте причину удержания ресурсов, чтобы избежать повторения проблемы.

Если хотите, могу добавить готовый playbook для автоматизированной диагностики и безопасного реагирования на случаи “filesystem busy” на вашем хостинге или кластере.