Как управлять службами в Linux через systemctl

Управление службой через systemctl начинается с двух независимых вопросов: работает ли она сейчас и настроен ли её запуск при загрузке? Служба может быть запущена вручную, но не включена в автозапуск. Возможна и обратная ситуация: автозапуск настроен, однако текущий запуск завершился ошибкой.
Инструкция относится к Linux с systemd. Ниже учебные команды для службы nginx.service; пакет и имя юнита должны действительно существовать на вашей машине. Это не журнал выполненных операций: примеры не запускались на реальном Linux-сервере. Изменяющие команды выполняйте только для службы, которую намерены обслуживать.
Что именно управляется
Unit — объект, которым управляет systemd. Есть юниты разных типов: службы, таймеры, сокеты и другие. Окончание .service обозначает службу, но не гарантирует наличие постоянно работающего процесса: конфигурация может описывать и однократную задачу.
Поэтому слово active нужно читать вместе с типом службы и подробным состоянием. Для длительно работающего сервера обычно ожидают active (running). Состояние active (exited) может быть нормальным для специально настроенной завершившейся задачи; само по себе оно не доказывает аварию.
Чтобы выяснить доступные имена, начните со списков. Не копируйте имя из чужого дистрибутива, если система отвечает, что такого юнита нет.
systemctl list-unit-files --type=service
systemctl list-units --type=service --all
systemctl list-units --type=service --state=failed
По руководству systemctl list-units показывает юниты, известные менеджеру в памяти; по умолчанию выводит активные, ожидающие задания или завершившиеся ошибкой. --all добавляет неактивные загруженные юниты. list-unit-files отвечает на другой вопрос: какие файлы юнитов установлены и каков их статус включения.
Как читать состояние
systemctl status nginx.service --no-pager
systemctl is-active nginx.service
systemctl is-enabled nginx.service
status удобен человеку: показывает сведения о юните, состояние и ограниченный фрагмент журнала. is-active даёт краткий ответ о текущей активности. is-enabled проверяет состояние включения файла юнита. Это не две формы одного и того же вопроса.
| Поле или состояние | Как понимать |
|---|---|
| Loaded | Откуда загружено описание и удалось ли его прочитать |
| Active: active | Юнит активен; подробность в скобках зависит от типа |
| inactive | Сейчас неактивен; это может быть обычная остановка |
| failed | Зафиксирована ошибка, например код завершения, сбой или тайм-аут |
| enabled | Созданы предусмотренные конфигурацией связи включения |
| disabled | Соответствующее включение не настроено; текущий процесс при этом может работать |
Ответ active не является проверкой сайта через HTTP или проверкой правильности бизнес-операций. После запуска веб-сервера отдельно проверяют доступность нужного адреса и ожидаемый ответ приложения.
Запуск, остановка и перечитывание настроек
sudo systemctl start nginx.service
sudo systemctl stop nginx.service
sudo systemctl restart nginx.service
sudo systemctl reload nginx.service
Это отдельные варианты действий, а не последовательность, которую нужно выполнить целиком. start активирует службу, stop останавливает. restart останавливает и запускает снова; если служба ещё не работала, команда её запускает. Планируйте перезапуск с учётом возможного перерыва обслуживания.
reload просит саму службу перечитать её конфигурацию. Возможность зависит от реализации службы и юнита. Нельзя считать, что reload всегда доступен или равнозначен restart. Если программа предусматривает проверку своего конфигурационного файла, сначала воспользуйтесь именно её способом проверки.
daemon-reload имеет другой смысл: он перечитывает описания юнитов systemd после изменения .service и связанных файлов. Он не заменяет перечитывание конфигурации nginx и сам по себе не перезапускает приложение.
sudo systemctl daemon-reload
После изменения юнита дальнейшее действие выбирают по характеру правки. Например, для нового параметра запуска работающему процессу может потребоваться перезапуск. Не добавляйте daemon-reload к каждой операции «на всякий случай»: сначала определите, какой файл изменён.
Автозапуск и текущее состояние
sudo systemctl enable nginx.service
sudo systemctl enable --now nginx.service
sudo systemctl disable nginx.service
sudo systemctl disable --now nginx.service
Это снова альтернативные команды. enable создаёт связи, указанные в секции [Install], и без --now не запускает службу немедленно. enable --now совмещает включение и запуск. disable без --now не останавливает уже работающую службу; disable --now добавляет остановку.
Отключённый автозапуск не равен запрету любых способов запуска. Службу могут активировать вручную либо через другие механизмы. Для специального запрета существует mask, но это уже отдельное административное решение, которое не следует подменять обычным disable.
Команда preset восстанавливает настройку включения по действующей политике preset-файлов. Она не означает «включить всё» и не является универсальным способом исправить проблему. На управляемой машине сначала выясните, какая политика должна применяться к этой службе.
Журнал вместо повторных перезапусков
sudo journalctl -u nginx.service -b -n 50 --no-pager
sudo journalctl -u nginx.service --since "30 minutes ago"
sudo journalctl -u nginx.service -f
-u ограничивает журнал указанным юнитом, -b выбирает текущую загрузку, -n 50 показывает последние 50 записей, --since задаёт временную границу. -f продолжает вывод новых записей; чтобы закончить наблюдение, нажмите Ctrl+C. Это завершает просмотр, а не саму службу.
Часть журнала может быть недоступна обычному пользователю. Недостаток прав не нужно интерпретировать как отсутствие событий. Используйте подходящие полномочия и не публикуйте журнал целиком без просмотра: сообщения могут содержать внутренние пути и данные приложения.
Учебный разбор ошибки
Предположим, после изменения настроек запуск завершился failed. Сначала запишите время попытки, затем откройте status и последние сообщения этого юнита. Найдите исходную ошибку перед итоговым «запуск не удался»: это может быть ошибка конфигурации, отсутствующий файл, занятый ресурс или недостаток прав. В примере это направления поиска, а не диагноз конкретной машины.
Исправив подтверждённую причину, повторите нужную операцию один раз и проверьте статус, свежий журнал и сам сервис. Команда reset-failed очищает сохранённое состояние ошибки и счётчики ограничений запуска, но не исправляет конфигурацию. Не используйте её вместо устранения причины.
При Unit not found проверьте имя и наличие пакета; при access denied — полномочия и контекст; при сообщении о неподдерживаемом reload — возможности службы. Если systemd не является менеджером текущего окружения, например в отдельной контейнерной конфигурации, сначала разберитесь с устройством среды. Повтор systemctl не создаст отсутствующий системный менеджер.



