Диагностика служб Linux с помощью systemctl и journalctl

Когда служба Linux выходит из строя, самый быстрый путь обычно — не поиск в интернете. Это три локальные проверки: что systemd думает о произошедшем, что залогировала служба и что изменилось до сбоя. systemctl и journalctl дают вам эти ответы без гаданий.

В этом руководстве в качестве примеров используются типичные сбои служб: служба, которая не запускается, процесс, который работает, но не выполняет полезной работы, и служба, которая завершается после того, как выглядела здоровой. Команды применимы к большинству служб, управляемых systemd, но точные имена модулей и расположения журналов различаются в зависимости от дистрибутива и пакета.

Понимание `systemctl` и `journalctl`

Прежде чем углубляться в устранение неполадок, важно понять роли этих двух основных инструментов:

systemctl: Эта команда является центральной утилитой для управления и запроса системы и менеджера служб systemd. Она позволяет запускать, останавливать, перезапускать, проверять статус, а также включать/отключать службы.
journalctl: Эта команда используется для запроса журнала systemd, который представляет собой централизованную систему ведения журнала. Он собирает журналы от ядра, системных служб и приложений, предоставляя единое представление о системных событиях. journalctl бесценен для понимания того, почему служба вышла из строя или повела себя неожиданно.

Типичные сценарии устранения неполадок и решения

Давайте рассмотрим типичные проблемы и способы их решения:

1. Служба не запустилась

Это, пожалуй, самая распространенная проблема. Вы пытаетесь запустить службу, и она сразу же выходит из строя.

Шаг 1: Проверьте статус службы

Используйте systemctl status, чтобы получить немедленный обзор состояния службы и последних записей журнала.

sudo systemctl status apache2.service

Ожидаемый вывод (иллюстративный — ваш может отличаться):

● apache2.service - The Apache HTTP Server
     Loaded: loaded (/lib/systemd/system/apache2.service; enabled; vendor preset: enabled)
     Active: **failed** (result: exit-code) since Tue 2023-10-27 10:00:00 UTC; 1min ago
       Docs: https://httpd.apache.org/docs/2.4/
    Process: 12345 ExecStart=/usr/sbin/apachectl start (code=exited, status=1/FAILURE)
   Main PID: 12345 (code=exited, status=1/FAILURE)

Oct 27 10:00:00 your-server systemd[1]: Starting The Apache HTTP Server...
Oct 27 10:00:00 your-server apachectl[12345]: AH00526: Syntax error on line 123 of /etc/apache2/apache2.conf:
Oct 27 10:00:00 your-server apachectl[12345]: Invalid Mutex directory in argument file: '/var/run/apache2/'
Oct 27 10:00:00 your-server systemd[1]: apache2.service: Main process exited, code=exited, status=1/FAILURE
Oct 27 10:00:00 your-server systemd[1]: **Failed** to start The Apache HTTP Server.
Oct 27 10:00:00 your-server systemd[1]: apache2.service: Unit entered failed state.

Анализ: Вывод systemctl status четко показывает Active: failed и предоставляет фрагмент сообщения об ошибке: Invalid Mutex directory in argument file: '/var/run/apache2/'. Это указывает на проблему с конфигурацией.

Шаг 2: Исследуйте журналы с помощью journalctl

Для получения более подробной информации используйте journalctl для просмотра журналов, относящихся к неисправной службе. Флаг -u указывает модуль (службу).

sudo journalctl -u apache2.service -xe

-u apache2.service: Фильтрует журналы для модуля apache2.service.
-x: Добавляет пояснения к некоторым сообщениям журнала.
-e: Переходит в конец журнала, показывая самые последние записи.

Возможные находки: Вывод journalctl может выявить больше контекста об ошибке конфигурации, проблемах с разрешениями или проблемах с зависимостями.

Шаг 3: Проверьте файлы конфигурации

Основываясь на сообщении об ошибке, проверьте соответствующие файлы конфигурации. В приведенном выше примере он указывает на /etc/apache2/apache2.conf и каталог /var/run/apache2/.

sudo nano /etc/apache2/apache2.conf

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

sudo mkdir -p /var/run/apache2/
sudo chown www-data:www-data /var/run/apache2/
sudo systemctl start apache2.service

Если ошибка указывает на проблему с синтаксисом, запустите собственную проверку конфигурации приложения перед повторным перезапуском:

sudo apachectl configtest
sudo nginx -t
sudo sshd -t

Специфичные для приложения валидаторы выявляют ошибки, которые systemd не может понять. Systemd знает, завершился ли процесс. Он не знает, указывает ли ваш блок server Nginx на неправильный файл сертификата или принадлежит ли директива Apache другому контексту.

2. Служба работает, но не отвечает

Иногда systemctl status показывает службу как active (running), но она не выполняет свою предполагаемую функцию (например, веб-сервер не обслуживает страницы).

Шаг 1: Проверьте статус службы и PID

Убедитесь, что она действительно работает и имеет идентификатор процесса (PID).

sudo systemctl status nginx.service

Если он показывает active (running), запишите PID.

Шаг 2: Проверьте журналы службы на наличие ошибок

Даже если она работает, служба может сталкиваться с внутренними ошибками, которые мешают ей правильно функционировать.

sudo journalctl -u nginx.service -f

-f: Отслеживает вывод журнала в реальном времени. Это полезно, если вы можете вызвать проблему (например, попытаться получить доступ к веб-странице), пока работает journalctl.

Шаг 3: Проверьте журналы, специфичные для приложения

Многие службы ведут свои собственные журналы в дополнение к журналу systemd. Для веб-серверов, таких как Nginx или Apache, проверьте их типичные расположения журналов (например, /var/log/nginx/error.log, /var/log/apache2/error.log).

sudo tail -n 50 /var/log/nginx/error.log

Шаг 4: Проверьте использование ресурсов

Перегруженная система может привести к тому, что службы перестанут отвечать.

 top
 htop
 free -h

Ищите высокую загрузку ЦП, памяти или дискового ввода-вывода процессами службы.

Также проверьте, прослушивает ли служба там, где вы ожидаете:

sudo ss -ltnp
sudo ss -lunp

Для веб-службы видеть nginx активным в systemctl — это только половина истории. Вам все еще нужно знать, привязан ли он к 0.0.0.0:80, 127.0.0.1:8080, сокету IPv6 или вообще ни к какому сокету. Правило брандмауэра, несоответствие обратного прокси или неправильный адрес привязки могут сделать здоровый процесс сломанным извне.

Решение: Если журналы указывают на проблемы или ресурсы перегружены, вам может потребоваться:

Оптимизировать конфигурации.
Перезапустить службу (sudo systemctl restart <имя_службы>.service).
Исследовать основные проблемы с системными ресурсами.
При необходимости увеличить системные ресурсы.

3. Служба неожиданно останавливается

Если служба, которая ранее работала, внезапно останавливается, это часто связано с необработанным исключением или тайм-аутом watchdog.

Шаг 1: Проверьте недавнюю историю с помощью journalctl

Используйте journalctl, чтобы увидеть, что произошло непосредственно перед остановкой службы. Флаги --since и --until могут быть полезны, если вы знаете примерное время.

sudo journalctl -u <имя_службы>.service --since "1 hour ago"

Или, чтобы увидеть все журналы, связанные со службой с момента последней загрузки:

sudo journalctl -u <имя_службы>.service -b

Шаг 2: Ищите дампы памяти или отчеты о сбоях

Если служба аварийно завершила работу, система могла создать дамп памяти или отчет о сбое.

ls -l /var/crash/

Шаг 3: Просмотрите файл модуля службы systemd

Проверьте файл модуля службы (обычно в /etc/systemd/system/ или /lib/systemd/system/) на наличие директив Restart= и настроек WatchdogSec=. Неправильная конфигурация Restart= или слишком короткий WatchdogSec= могут вызвать неожиданные перезапуски или сбои.

systemctl cat <имя_службы>.service

Решение: Устраните основную причину, выявленную в журналах. Это может включать исправление ошибок в коде, настройку параметров файла модуля systemd или увеличение лимитов ресурсов.

Если вы видите повторяющиеся перезапуски, проверьте, не ограничил ли systemd скорость запуска модуля:

systemctl status <имя_службы>.service
journalctl -u <имя_службы>.service --since "30 minutes ago"

Сообщения о Start request repeated too quickly обычно означают, что служба несколько раз аварийно завершила работу за короткий промежуток времени. После устранения основной проблемы сбросьте состояние сбоя:

sudo systemctl reset-failed <имя_службы>.service
sudo systemctl start <имя_службы>.service

4. Проблемы с `systemctl enable` или `systemctl disable`

Хотя это и не ошибка времени выполнения, могут возникнуть проблемы с включением или отключением служб.

Проблема: Служба включена, но не запускается при загрузке, или наоборот.

Проверьте статус:

sudo systemctl is-enabled <имя_службы>.service

Эта команда выведет enabled или disabled.

Устранение неполадок:

Убедитесь, что файл модуля службы действителен и размещен правильно (например, /etc/systemd/system/).
После внесения изменений в файл модуля всегда выполняйте sudo systemctl daemon-reload.
Проверьте журналы службы (journalctl -u <имя_службы>.service) на наличие ошибок запуска, которые могут помешать ей стать активной, даже если она включена.

Советы по эффективному устранению неполадок

Начинайте с systemctl status: Всегда начинайте здесь. Это дает быстрый снимок и часто указывает вам правильное направление.
Используйте journalctl -u <служба>: Это ваш основной инструмент для понимания того, почему что-то происходит.
Флаг -f с journalctl: Чрезвычайно полезен для мониторинга в реальном времени при попытке воспроизвести проблему.
systemctl restart <служба>: После внесения изменений в конфигурацию всегда перезапускайте службу, чтобы применить их.
systemctl daemon-reload: Критически важно после изменения любых файлов модулей .service.
Проверяйте зависимости: Иногда служба выходит из строя, потому что служба, от которой она зависит, не запустилась или сама выходит из строя. systemctl status часто показывает это.
Разрешения: Многие сбои служб связаны с неправильными разрешениями файлов или каталогов. Убедитесь, что пользователь, от имени которого работает служба, имеет необходимый доступ.
Сетевые проблемы: Если служба полагается на сеть, проверьте сетевое подключение, правила брандмауэра и доступность портов.

Порядок устранения неполадок, который работает

Когда давление велико, используйте один и тот же порядок каждый раз:

systemctl status <служба>.service
journalctl -u <служба>.service -b --no-pager
systemctl cat <служба>.service
systemctl list-dependencies <служба>.service

Начните с текущего состояния, затем прочитайте журналы текущей загрузки, затем проверьте модуль точно так, как его видит systemd, затем проверьте зависимости. Если служба сетевая, добавьте ss -ltnp и локальный curl или клиентский тест. Если она читает файл конфигурации, запустите собственный валидатор конфигурации службы.

Смысл в том, чтобы избегать случайных перезапусков. Перезапуск может быть допустимым исправлением после изменения конфигурации или зависшего процесса, но он также уничтожает улики. Сначала прочитайте достаточно журнала, чтобы знать, что вы меняете и почему.

Чтение вывода журнала без потери ориентации

journalctl может быть шумным, особенно на загруженных серверах. Начинайте с узкого, затем расширяйте только при необходимости.

Для одной службы в текущей загрузке:

journalctl -u <служба>.service -b --no-pager

За последние несколько минут:

journalctl -u <служба>.service --since "15 minutes ago" --no-pager

Для предыдущей загрузки:

journalctl -u <служба>.service -b -1 --no-pager

Этот просмотр предыдущей загрузки полезен, когда служба вышла из строя во время запуска, а затем восстановилась, или когда вся машина перезагрузилась до того, как вы смогли ее проверить. Вы можете вывести список загрузок с помощью:

journalctl --list-boots

Если служба регистрирует структурированные поля или длинные строки, используйте короткие временные метки ISO:

journalctl -u <служба>.service -o short-iso --no-pager

Когда вам нужно поделиться журналами, удалите секреты, токены, внутренние имена хостов и данные клиентов. Журналы служб часто включают настройки, полученные из окружения, URL-адреса, заголовки или строки подключения. Чистая привычка устранения неполадок включает редактирование перед вставкой вывода куда-либо.

Когда systemctl говорит "Active", но пользователи все еще видят сбой

Состояние active (running) означает только то, что у systemd есть процесс, который соответствует ожиданиям модуля. Это не доказывает, что приложение здорово. Веб-приложение может работать, возвращая HTTP 500. Рабочий процесс может быть активным, но зависнуть на плохом сообщении очереди. Прокси базы данных может работать, в то время как все внутренние соединения терпят неудачу.

Для сетевых служб тестируйте с тех же уровней, от которых зависят ваши пользователи:

curl -v http://127.0.0.1:8080/health
curl -v http://localhost/health
curl -v https://service.example.com/health

Эти три проверки отвечают на разные вопросы. Первая проверяет локальный порт приложения. Вторая может включать локальный обратный прокси. Третья проверяет DNS, TLS, маршрутизацию, правила брандмауэра и общедоступный путь.

Для рабочих служб смотрите на то, что они потребляют или производят. Рабочему процессу очереди может потребоваться проверка глубины очереди. Службе резервного копирования может потребоваться недавний выходной файл. Сборщику метрик может потребоваться запрос к бэкенду метрик. systemctl сообщает вам, работает ли надзор; проверки приложений сообщают вам, полезна ли служба.

Исправляйте одну переменную за раз

Когда модуль выходит из строя после развертывания, возникает соблазн изменить несколько вещей и перезапустить. Это может скрыть реальную причину. Предпочитайте одно изменение за раз:

systemctl cat my-app.service
journalctl -u my-app.service --since "30 minutes ago" --no-pager
sudo systemctl edit my-app.service
sudo systemctl daemon-reload
sudo systemctl restart my-app.service

Затем проверьте результат, прежде чем менять следующее. Если сбой связан с отсутствующим файлом, исправьте путь к файлу. Если это ошибка разрешения, исправьте владельца или режим. Если это зависимость, исправьте отношение модуля или поведение повторных попыток приложения. Медленное, скучное устранение неполадок часто быстрее, чем цикл перезапуска с пятью неотслеживаемыми правками.