sudo systemctl restart nginx && systemctl is-active nginx перезапускает сервис и печатает одно слово о том, работает ли он на самом деле. Сам restart молчит и при успехе, и когда процесс умер через секунду, поэтому проверка — отдельная команда. А is-active отвечает inactive и на опечатку в имени юнита: именно здесь себя чаще всего и обманывают.
1. Перезапустить и проверить одной строкой
$ clai перезапусти docker и скажи, поднялся ли он→ sudo systemctl restart docker && systemctl is-active dockeractiverestart при успехе не печатает ничего, а молчание ничего не доказывает. is-active возвращает одно слово и код 0 — как раз то, что нужно после &&.
2. Ловушка: опечатка в имени юнита
$ clai проверь, работает ли сервис nosuch→ systemctl is-active nosuch.serviceinactiveНесуществующий юнит отвечает inactive с кодом возврата 4, а не «unit not found». В скрипте это читается как «сервис остановлен», хотя на самом деле вы ошиблись в имени. status честнее: Unit nosuch.service could not be found.
3. Что на самом деле говорит status
$ clai покажи состояние сервиса docker→ systemctl status docker● docker.service - Docker Application Container Engine Loaded: loaded (/usr/lib/systemd/system/docker.service; enabled; preset: enabled) Active: active (running) since Mon 2026-08-24 14:15:54 +07; 3 days ago Invocation: ca41df104d0f46f5a69c964621baf011TriggeredBy: ● docker.socket Docs: https://docs.docker.comСмысл несут две строки. Loaded говорит, что юнит-файл найден, а enabled — что сервис стартует при загрузке. В Active стоит время работы: если там секунды, а перезапускали вы минуту назад, значит сервис успел упасть и подняться сам.
4. Проверка для скрипта, а не для глаз
$ clai покажи состояние docker в машиночитаемом виде→ systemctl show -p ActiveState,SubState,MainPID,NRestarts dockerActiveState=activeSubState=runningMainPID=5425NRestarts=0show ничего не форматирует для человека, поэтому переживает обновления systemd, которые меняют красивый вывод. Растущий NRestarts — самый быстрый признак того, что политика Restart= прикрывает вечный цикл падений.
5. Найти всё, что упало
$ clai покажи упавшие сервисы→ systemctl --failed UNIT LOAD ACTIVE SUB DESCRIPTION● logrotate.service loaded failed failed Rotate log filesКоротко и по делу. Для одного юнита systemctl is-failed <имя> печатает failed и выходит с кодом 0, если юнит действительно в этом состоянии.
6. Сбросить состояние failed
$ clai сбрось состояние ошибки у сервиса logrotate→ sudo systemctl reset-failed logrotate.serviceПока состояние не сброшено, юнит висит в списке --failed, а счётчик StartLimitBurst может отказать в новых попытках старта со словами «start request repeated too quickly». reset-failed обнуляет счётчик и убирает юнит из списка.
Gotchas
- Тишина после restart ничего не доказывает.
systemctl restartпечатает пустоту и когда сервис здоров, и когда он умер через секунду. Проверка — всегда отдельная команда. is-activeне отличает опечатку от остановленного сервиса. Оба случая даютinactive. Коды возврата разные — 4 у несуществующего юнита, — но глазами их не видно, поэтому при неожиданном ответе сразу смотритеstatus.restartне перечитывает изменённый юнит-файл. После правки.serviceнуженsudo systemctl daemon-reload, иначе systemd запустит старую версию, и вы будете искать ошибку в конфиге, который уже исправлен.
Related questions
Чем restart отличается от reload? reload просит сам сервис перечитать конфиг, не разрывая соединения; restart убивает процесс и запускает заново. Если юнит не умеет reload, reload-or-restart выберет доступный вариант.
Как понять, почему сервис не поднялся? journalctl -u <имя> -n 50 -o cat покажет последние строки лога без служебных префиксов — причина обычно там.
Как убедиться, что он переживёт перезагрузку? systemctl is-enabled <имя> отвечает enabled или disabled. Работающий прямо сейчас сервис вполне может быть disabled и не вернуться после ребута.
See also
CliAI превращает «перезапусти и скажи, поднялся ли» в обе команды сразу и показывает их до запуска. Поставить одной строкой.