Перейти к содержанию

Лабораторная: сбои systemd

В паре со статьёй: Устройство systemd

Окружение: одна одноразовая VM.

Начальные условия

  1. Создайте тестовый сервис, точно как в упражнении родительской статьи:
# /etc/systemd/system/labapp.service
[Unit]
Description=Lab Test Application
After=network.target

[Service]
Type=simple
ExecStart=/usr/bin/sleep infinity
Restart=on-failure
RestartSec=5

[Install]
WantedBy=multi-user.target

sudo systemctl daemon-reload
sudo systemctl enable --now labapp.service
  1. Убедитесь, что systemctl status labapp показывает active (running).

Инструкции

Часть 1 — Сломайте намеренно

Внесите одну из следующих неисправностей:

  • Цикл падений: измените ExecStart на команду, которая падает немедленно и постоянно, например /bin/false, оставив Restart=on-failure и короткий RestartSec. Выполните daemon-reload и перезапустите юнит.
  • Сбой зависимости: добавьте Requires=nonexistent.service в секцию [Unit] (ссылка на несуществующий юнит), daemon-reload, затем попробуйте запустить.
  • Неверный пользователь: добавьте User=nonexistentuser в [Service] (учётная запись, которой не существует в этой системе), daemon-reload, перезапуск.

Часть 2 — Диагностируйте

Используя systemctl status labapp и journalctl -u labapp, определите:

  1. Считается ли юнит failed, или он застрял в каком-то другом состоянии?
  2. Какую конкретную ошибку показывает journalctl, и указывает ли она прямо на реальную первопричину, или нужно о ней порассуждать?

Ожидаемые результаты

  • Неисправность цикла падений: systemctl status покажет быстрые попытки перезапуска; если число перезапусков превышает StartLimitBurst по умолчанию (5 за 10 секунд) в этом окне, systemd прекращает попытки, и юнит оказывается в состоянии failed с сообщением Start request repeated too quickly в журнале — очень конкретное, легко находимое сообщение.
  • Неисправность сбоя зависимости: systemctl start labapp падает немедленно с сообщением, что юнит-зависимость не найден; journalctl сошлётся на отсутствующий юнит напрямую по имени.
  • Неисправность неверного пользователя: сервис не запускается с кодом выхода вида status=217/USER (или похожим), видимым прямо в выводе systemctl status, без необходимости вообще копаться в journalctl для этого конкретного случая — сам код выхода и есть диагностика.

Чек-лист диагностики

  • [ ] Проверили ли вы в systemctl status конкретный status=<код>/<причина> последнего выхода, а не только надпись failed?
  • [ ] Для неисправности цикла падений: распознали ли вы StartLimitBurst/ StartLimitIntervalSec как механизм, который в итоге останавливает метания, а не бесконечный цикл?
  • [ ] Показал ли journalctl -u labapp --since "5 min ago" достаточно истории, чтобы увидеть паттерн (быстрые повторные запуски), или понадобилось скорректировать --since, чтобы его захватить?

Критерии успеха

При любой из трёх неисправностей (не зная заранее, какая именно) вы можете назвать конкретную первопричину — не просто «он упал» — используя только systemctl status и journalctl -u labapp, в течение одной минуты.

Очистка / откат

sudo systemctl disable --now labapp.service
sudo rm /etc/systemd/system/labapp.service
sudo systemctl daemon-reload
sudo systemctl reset-failed labapp.service   # сбросить запись о зависшем "failed"-состоянии

Убедитесь, что systemctl status labapp теперь сообщает Unit labapp.service could not be found, прежде чем считать окружение очищенным.