Debugging

Когда сервис падает, а логов недостаточно, следующий шаг — gdb. Не обязательно быть C-разработчиком: базовых команд хватает, чтобы вытащить стек вызовов и переменные на момент краха. gdb -p $(pgrep myapp) # подключиться к живому процессу gdb --args ./myapp --config prod.conf (gdb) bt # backtrace — стек вызовов (gdb) info locals # переменные текущего фрейма (gdb) frame 2 # переключиться на фрейм (gdb) print my_var (gdb) continue Для уже случившегося краха без живого процесса — gdb ./myapp core.12345: bt покажет строку и стек на момент сигнала. Без -g при сборке символов нет, bt покажет только адреса — но иногда и этого хватает понять, в какой библиотеке крах. ...

Динамически слинкованный бинарник не содержит код библиотек внутри — при запуске загрузчик находит .so-файлы по путям из кэша. ldd, ldconfig и LD_PRELOAD управляют этим процессом, пригождаются при error while loading shared libraries. # какие .so нужны бинарнику и откуда они реально берутся ldd /usr/bin/nginx # обновить кэш путей после установки новой библиотеки в нестандартный путь ldconfig ldconfig -p | grep libssl # проверить, что библиотека в кэше # подменить библиотеку на лету, без пересборки бинарника LD_PRELOAD=/opt/libs/libfake.so ./app LD_PRELOAD удобен для отладки и быстрых хаков без правки исходников, но тем же механизмом пользуются руткиты — лишняя строка в выводе ldd повод проверить /etc/ld.so.preload. ...