Когда сервис завис, тупит на старте, не открывает файлы или просто ведёт себя странно, а в логах ничего — почти всегда первым делом имеет смысл запустить
strace. Он показывает системные вызовы процесса, то есть что программа на самом деле просит у ядра.Запускаем программу под трассировкой:
strace ls /tmp
Сразу видно, какие файлы открываются, какие библиотеки грузятся, где возникают ошибки.
Можно прицепиться к уже работающему процессу — удобно, если сервис завис:
sudo strace -p <PID>
Обычно быстро становится понятно, где он застрял:
futex (блокировка), ожидание I/O (poll/epoll_wait), connect, чтение/запись и т.п.Если программа создаёт дочерние процессы, без этого ключа часть событий не попадёт в вывод:
strace -f <command>
Проблемы с файлами, конфигами и правами:
strace -e trace=%file <command>
Покажет
open/stat/access и другие файловые операции — удобно понять, какие пути реально проверяются.Частый кейс — программа ищет файл, которого нет:
strace -e trace=%file <command> 2>&1 | grep ENOENT
Сразу видно, какой путь оказался отсутствующим.
Для сетевых проблем:
strace -e trace=%network <command>
Видно создание сокетов, попытки подключения и ошибки.
Если нужно сохранить вывод:
strace -o trace.log <command>
С дочерними процессами лучше так:
strace -ff -o trace.log <command>
Будут отдельные файлы по PID.
Иногда вывод обрезает длинные строки — увеличиваем лимит:
strace -s 200 <command>
Посмотреть, где именно тратится время:
strace -T <command>
Короткая сводка по системным вызовам:
strace -c <command>
🔥
strace незаменим при анализе поведения непрозрачных бинарников и в случаях, когда нет доступа к исходному коду. Он показывает, на каких системных вызовах процесс блокируется и какие операции фактически выполняет в пространстве ядра.➡️ DevOps Ready | #практика