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

Допустим, сервер отвечает по SSH, сайт перестал открываться, а приложение использует Docker. Перезапускать сразу все три службы — плохой способ выяснить причину. Сначала нужно понять, какая служба отвечает за нужную часть системы, как она называется и что сообщает её журнал.

Ниже авторский маршрут диагностики Linux с systemd. Имена sshd.service, nginx.service и docker.service приведены как примеры: фактические имена, наличие пакетов и способ запуска зависят от машины. Команды здесь не исполнялись на рабочем сервере, а сообщения описывают условные ситуации.

Daemon и service: связанные, но разные понятия

Словом daemon обычно называют фоновый процесс, выполняющий системную или прикладную работу. Service в systemd — управляемая служба, описанная юнитом .service. Она может запускать такой процесс, но может быть и однократной задачей с завершением. Поэтому службу нельзя определять только как «процесс, который всегда висит в памяти».

systemctl работает с юнитами менеджера systemd. Он не является универсальной командой для управления любым процессом или любым контейнером. Запуск Docker как системной службы и состояние отдельного контейнера — разные уровни проверки.

Для начала найдите установленные имена и посмотрите текущие состояния:

systemctl list-unit-files --type=service
systemctl list-units --type=service --all
systemctl status nginx.service --no-pager

Первый список описывает установленные файлы юнитов, второй — известные менеджеру юниты, включая неактивные с --all. Они не обязаны совпадать. Если ожидаемого имени нет, проверьте установку и документацию дистрибутива, а не создавайте пустой юнит для устранения сообщения.

Три состояния, которые нельзя смешивать

В status читайте Loaded и Active. Loaded помогает понять, найдено ли описание и откуда оно загружено. Active показывает текущее состояние. Дополнительные сведения о процессе и последние сообщения полезны, но короткий вывод не заменяет полный журнал нужного периода.

Состояние	Обычное значение	Что проверить
active	Юнит активен	Подсостояние running или exited, тип службы и работу приложения
inactive	Юнит неактивен	Ожидается ли сейчас работа или была штатная остановка
failed	Менеджер зафиксировал ошибку	Причину в журнале, код завершения и время события

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

systemctl is-active nginx.service
systemctl is-enabled nginx.service

Первая команда отвечает о текущей активности, вторая — о включении файла юнита. enabled и active нельзя использовать как синонимы. Процесс может работать после ручного запуска при disabled и не работать при enabled из-за ошибки.

Выбор операции вместо цепочки команд

Следующие строки — отдельные варианты. Не выполняйте все подряд:

sudo systemctl start nginx.service
sudo systemctl stop nginx.service
sudo systemctl restart nginx.service
sudo systemctl reload nginx.service

start запускает службу, stop останавливает, restart останавливает и запускает снова. Если служба не работала, restart тоже её запустит. reload просит перечитать собственную конфигурацию приложения, если такая операция поддерживается. Возможность reload нужно проверять для конкретной службы.

После изменения описания юнита systemd используется daemon-reload. Он перечитывает файлы менеджера, но не является перезапуском приложения и не заменяет его reload. Если меняли настройки самого веб-сервера, способ проверки и применения выбирают по документации веб-сервера.

Автозагрузка: отдельное решение

sudo systemctl enable nginx.service
sudo systemctl enable --now nginx.service
sudo systemctl disable nginx.service

Первая строка настраивает связи включения по секции [Install], но не запускает службу сейчас. Вторая добавляет немедленный запуск. Третья отключает соответствующие связи, но сама не останавливает работающий процесс. Для совмещения отключения с остановкой есть disable --now, если именно это требуется.

Включение не является проверкой корректности конфигурации. После enable --now отдельно посмотрите состояние и результат работы. Некоторые юниты не предназначены для прямого enable и активируются через зависимости или другие механизмы. Сообщение об этом требует понимания устройства службы, а не принудительного создания ссылок.

Журнал и исходная причина

sudo journalctl -u nginx.service -b -n 80 --no-pager
sudo journalctl -u nginx.service --since "20 minutes ago"
sudo journalctl -u nginx.service -f

Фильтр -u выбирает юнит, -b — текущую загрузку, -n 80 — последние 80 записей. --since ограничивает время, а -f позволяет наблюдать новые сообщения. Ctrl+C заканчивает такой просмотр, не останавливая nginx.

В условном случае перезапуск завершился failed. Найдите сообщения непосредственно перед итоговым сообщением systemd: какая команда не выполнилась, какой файл или ресурс упомянут. Сохраните исходную ошибку, внесите одну обоснованную правку и повторите проверку. Повторные restart без изменения причины только добавляют одинаковые события.

Доступ к системному журналу зависит от прав. Если вывод пуст или ограничен, проверьте полномочия и период. Прежде чем передавать журнал коллеге, просмотрите его на наличие токенов, персональных данных и внутренних реквизитов приложения.

SSH, nginx и Docker в одном маршруте

SSH. При проблеме нового подключения сначала установите реальное имя службы: в одних установках это sshd.service, в других встречается ssh.service. По найденному имени откройте status и журнал. Если сейчас работаете через единственное удалённое соединение, сначала обеспечьте возможность восстановления доступа, а затем планируйте меняющие операции.

nginx. Если сайт не отвечает, проверьте nginx.service, сообщения его запуска и фактический HTTP-ответ. Работающий процесс не исключает неверного виртуального хоста, недоступного приложения за прокси или сетевой проблемы. Это варианты дальнейшего поиска, а не основания перезапускать всё сразу.

Docker. Для системной установки откройте status docker.service и журнал того же юнита. Если демон работает, но один контейнер не обслуживает запросы, продолжайте диагностику контейнера средствами вашей установки. Перезапуск демона — изменение более широкого уровня, чем исправление одного приложения, и его последствия нужно оценивать отдельно.

Завершённая проверка состоит из подтверждённой причины, подходящего действия и проверки результата. Запишите, что меняли и что наблюдали. Если ошибка вернулась, сохранённые время и сообщения полезнее памяти о том, что «после третьего перезапуска вроде заработало».