Диагностика неполадок в Linux: 4 шага, которые закрывают почти все случаи
Ошибки в Linux редко решаются угадыванием. Гораздо продуктивнее придерживаться последовательного, воспроизводимого процесса. Удобная схема — GLAD: Gather (собрать факты), Look (посмотреть состояние и логи), Analyze (проанализировать и проверить гипотезы), Document (задокументировать решение). Такой подход экономит время, снижает риск усугубить проблему и помогает находить первопричину, а не лечить симптомы.
Шаг 1. Соберите факты и сформулируйте проблему
- Точность формулировки. Замените «сервер умер» на «Nginx возвращает 503 на /api/users при нагрузке >100 RPS» или «после обновления ядра система зависает на стадии initramfs».
- Контекст. Когда началось? Что менялось прямо перед инцидентом: пакеты, конфигурация, права, ядро, железо, параметры запуска?
- Воспроизводимость. Можно ли стабильно вызвать ошибку? Повторяемость — лучший друг диагностики.
- Симптомы и сообщения. Снимите точный вывод ошибок: запустите программу из терминала, сохраните коды, трассировки, тексты panic/kernel oops, приглашение grub rescue.
- Границы проблемы. Это локальная ошибка конкретного сервиса или системная? Страдают ли другие процессы, сеть, диск?
Шаг 2. Посмотрите на состояние системы и логи
- Ресурсы. top/htop для CPU и ОЗУ, free -h, vmstat, iostat/atop для диска, df -h и du для свободного пространства, ss -tulpn или netstat для сокетов, ip a/ip r для сети, ping/traceroute для связности.
- Системные логи. journalctl -xb для текущей загрузки, dmesg для событий ядра. Для сервисов: systemctl status , journalctl -u --since "..." —until "...".
- Логи приложений. Ищите файлы в /var/log/ и директориях конкретных демонов; читайте фрагменты вокруг момента ошибки.
- События безопасности. Проверяйте SELinux/AppArmor: audit логи и статус режимов (enforcing/permissive). Ошибки доступа часто маскируются под «не запускается».
- Ограничения. ulimit -a, cgroups/systemd Limits, параметры в unit-файлах (MemoryMax, LimitNOFILE). Переполненный инод, недостаток дескрипторов или OOM-killer — частые неожиданности.
Шаг 3. Проанализируйте и проверьте гипотезы
- Выдвигайте версии причин, а затем проверяйте их по одной. Меняйте лишь один фактор за итерацию: конфиг, переменные окружения, версию пакета, параметры запуска.
- Минимизируйте среду. Запускайте сервис вручную с явным конфигом и детальным логированием; подменяйте зависимости на заглушки; отключайте лишнее, чтобы сузить область поиска.
- Используйте инструменты диагностики:
- strace/ptrace для системных вызовов и ошибок EACCES/ENOENT.
- lsof/ss для занятых портов и открытых файлов.
- systemd-analyze для анализа загрузки.
- diff/meld для сравнения конфигов и единиц systemd.
- ldconfig/ldd для проблем с динамическими библиотеками.
- Проверяйте гипотезы безопасно: делайте бэкап конфигов, снимайте снапшоты, применяйте staged rollout, используйте временные изменения через drop-in unit’ов, а не правьте бинарники.
Шаг 4. Задокументируйте решение
- Кратко опишите симптомы, первопричину, шаги исправления и валидацию результата.
- Сохраните команды, вывод, контрольные точки и итоговое состояние конфигов.
- Добавьте раздел «как не допустить повторения»: мониторинг, алерты, лимиты, миграция на стабильные версии, тесты запуска.
Разбор частых сценариев
1) Система не загружается
- Симптомы: kernel panic, зависание на initramfs, сообщение от GRUB.
- Действия:
- journalctl -xb из chroot или просмотр /var/log/ за предыдущую загрузку, dmesg в режиме восстановления.
- Проверка целостности диска (fsck), статуса RAID/LVM, наличия и корректности UUID в /etc/fstab, загрузочных флагов, версий initramfs.
- Пересборка initramfs и обновление загрузчика: dracut/update-initramfs, проверка конфигурации GRUB и правильности root= в параметрах ядра.
- Откат на предыдущее ядро при подозрении на несовместимость модулей или драйверов.
- Частые причины: неверный UUID, сломанный модуль файловой системы, битый диск, ошибки после обновления ядра, конфликт видеодрайвера.
2) Приложение отказывается запускаться
- Симптомы: процесс мгновенно завершается, коды возврата, отсутствие окна GUI, «permission denied».
- Действия:
- Запуск из терминала для получения явных ошибок; проверка зависимостей через ldd.
- Валидация прав на бинарник и каталоги, принадлежности пользователя, наличия нужных директорий /var/run, /var/lib.
- Проверка окружения: PATH, LD_LIBRARY_PATH, locale, конфигов. Часто ломается из‑за отсутствующих переменных или неверных путей.
- SELinux/AppArmor: временно перевести в permissive для проверки гипотезы и затем оформить корректную политику.
- Частые причины: несовместимая версия библиотеки, неверные права/владение, отсутствующая директория для сокета/кеша, конфликты портов.
3) Nginx или другой сервис сетевого уровня падает или отдаёт 5xx
- Симптомы: 502/503/504, отказ старта, «address already in use».
- Действия:
- nginx -t для синтаксиса, проверка включаемых конфигов и прав на cert/key.
- ss -ltnp для портов, кто держит 80/443; в случае конфликта изменить bind или освободить порт.
- Проверка upstream: доступность бекенда, таймауты, лимиты соединений, заголовки, размер тел (client_max_body_size).
- Ограничения ОС: лимиты на открытые файлы, worker_rlimit/worker_connections в конфиге, параметры ядра net.core.somaxconn и пр.
- Частые причины: недоступный бекенд, конфликт портов, неверные сертификаты/права, исчерпаны дескрипторы.
4) Контейнер Docker не стартует
- Симптомы: перезапуски по кругу, exit code, ошибки монтирования, permission denied при доступе к сокетам/устройствам.
- Действия:
- docker logs , docker inspect для разбора параметров, точный command/entrypoint.
- Проверка томов и прав на хосте для bind‑mount, SELinux контексты для директорий, соответствие user/group.
- Проверка портов, конфликтов с уже занятыми адресами; просмотр ресурсов cgroup, лимитов памяти/CPU.
- Если процесс внутри завершается сразу — запустить аналогичный образ в интерактивном режиме и воспроизвести команду вручную, подключив strace.
- Частые причины: битая конфигурация окружения, неправильные пути монтирования, ограничения безопасности, несоответствие версий образа и ядра.
Практические приёмы, которые экономят часы
- Делайте «снимок» состояния перед изменениями: копии конфигов, список установленных пакетов, версия ядра, вывод systemctl list-units — это помогает откатить и сравнить.
- Ведите журнал действий: команда — результат — вывод. Это дисциплина, которая ускоряет диагностику и облегчает документирование.
- Автоматизируйте сбор данных: простые скрипты, которые собирают логи, версию ОС, метрики ресурсов, статусы сервисов.
- Разделяйте причину и следствие: «упал сервис» часто следствие, а причина — заполненный диск, OOM или потеря DNS.
- Проверяйте «простые» вещи первыми: свободное место, права, порт, сеть, часы (NTP). Несинхронизированное время ломает TLS и кластеры.
- Используйте канареечную проверку: прежде чем внедрять правку глобально, убедитесь на одной ноде, что гипотеза верна.
- Воспроизводимый стенд: держите тестовую VM/контейнер для экспериментов, где можно свободно включать/выключать модули и проверять параметры ядра.
- Снимайте «тепловую карту» изменений: если после апдейта сломалось — просмотрите список обновлённых пакетов, diff конфигов и юнитов.
Как убедиться, что исправление действительно работает
- Тестируйте по исходным симптомам: тот же запрос, та же нагрузка, та же последовательность действий.
- Включите дополнительное логирование на время проверки и уберите после подтверждения стабильности.
- Наблюдайте метрики после фикса: ошибки, задержки, использование ресурсов, количество рестартов сервисов.
- Ищите побочные эффекты: исправляя одно, легко ухудшить другое. Регрессия — реальный риск.
Что включить в итоговую документацию
- Краткое описание инцидента и временная шкала.
- Точная первопричина и как её обнаружили.
- Конкретные действия по исправлению с командами и конфигами.
- Рекомендации по профилактике: мониторинг, лимиты, алерты, обновления по расписанию, тесты на запуск/конфликт портов.
- Чек‑лист на будущее для быстрого трияжа аналогичных случаев.
Итог
Почти любую проблему в Linux можно «размотать», если не спешить и идти по понятной схеме: собрать факты, проверить состояние и логи, сформировать и аккуратно проверить гипотезы, затем зафиксировать знания. GLAD — это не магия, а дисциплина, которая превращает хаос в управляемый процесс и экономит время при следующем инциденте.
