systemd и systemctl: как управлять сервисами в Linux

systemd как система инициализации современного Linux

systemd — это система инициализации, которая на подавляющем большинстве современных дистрибутивов Linux (Ubuntu, Debian, CentOS, AlmaLinux и многих других) первой запускается ядром при загрузке и затем управляет всеми остальными фоновыми службами (сервисами) на протяжении всей работы сервера: веб-сервером, базой данных, SSH-демоном и любыми другими долго работающими процессами.

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

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

Общая характеристика systemd в документации по системному администрированию Linux

Эта статья разбирает основные команды systemctl для повседневного управления сервисами, диагностику ситуации, когда служба отказывается запускаться, написание собственного минимального unit-файла для своего скрипта или приложения, и сравнение systemd timers с классическим cron для задач по расписанию.

Базовые команды systemctl

Управление конкретной службой сводится к небольшому набору команд, названия которых интуитивно соответствуют выполняемому действию. start запускает службу немедленно, stop останавливает её, restart полностью перезапускает (сначала останавливает, затем снова запускает), а status показывает текущее состояние вместе с последними строками журнала.

systemctl start nginx\nsystemctl stop nginx\nsystemctl restart nginx\nsystemctl status nginx

Отдельная команда reload отличается от restart принципиально: вместо полной остановки и повторного запуска процесса она отправляет ему сигнал перечитать конфигурацию на лету, не прерывая уже установленные соединения и не создавая кратковременного простоя в обслуживании запросов. Это работает только для служб, чей процесс явно поддерживает такой сигнал (nginx поддерживает, многие другие сервисы — нет), поэтому reload — не универсальная более мягкая замена restart, а отдельная возможность, доступная не для каждой службы.

systemctl reload nginx

Команды enable и disable управляют автозапуском службы при загрузке системы, что принципиально отдельно от того, запущена ли служба прямо сейчас. enable создаёт символическую ссылку на unit-файл в соответствующем каталоге автозапуска, благодаря которой служба стартует автоматически при каждой последующей загрузке сервера; сама по себе команда enable не запускает службу немедленно, если она ещё не запущена, — для этого по-прежнему нужен отдельный вызов start.

systemctl enable nginx\nsystemctl enable --now nginx

Флаг --now, добавленный к enable или disable, объединяет обе операции в одну команду — включает автозапуск и сразу запускает службу, либо отключает автозапуск и сразу останавливает её, что удобнее двух последовательных вызовов при первичной настройке нового сервиса на сервере.

Диагностика: почему сервис не запускается

Когда служба отказывается запускаться, первый и самый быстрый источник информации — вывод команды systemctl status для этой конкретной службы: он показывает текущее состояние (active, failed, inactive), код завершения последнего процесса и, как правило, последние несколько строк из журнала этой службы прямо в том же выводе, без необходимости отдельно запускать journalctl.

systemctl status php8.3-fpm

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

journalctl -u php8.3-fpm -p err --since "1 hour ago"

Частые причины неудачного запуска службы: синтаксическая ошибка в её собственном конфигурационном файле (это касается прежде всего nginx, php-fpm и подобных приложений, а не самого unit-файла systemd), занятый порт, на который служба пытается забиндиться, что часто происходит при попытке запустить второй экземпляр той же или конфликтующей службы, и недостаточные права доступа к файлам или каталогам, которые служба пытается открыть при старте — та же проблема, что разобрана в отдельной статье про права доступа Linux.

nginx -t\nphp-fpm8.3 -t

Проверка синтаксиса конфигурации самой командой приложения (флаг -t у nginx и многих других сервисов) до перезапуска через systemctl экономит время — гораздо быстрее сразу узнать про опечатку в конфигурационном файле напрямую, чем несколько раз перезапускать службу через systemctl и каждый раз заново лезть в journalctl за подробностями одной и той же ошибки.

Структура минимального unit-файла для собственного сервиса

Собственный скрипт или небольшое приложение, которое должно работать постоянно (в отличие от разовой или периодической задачи, для которой больше подходит cron) и автоматически перезапускаться при аварийном завершении, разумно оформить как управляемый systemd сервис через собственный unit-файл, а не запускать вручную в фоне через nohup или screen.

# /etc/systemd/system/myapp.service\n[Unit]\nDescription=Моё фоновое приложение\nAfter=network.target\n\n[Service]\nType=simple\nUser=www-data\nWorkingDirectory=/var/www/myapp\nExecStart=/usr/bin/php /var/www/myapp/worker.php\nRestart=on-failure\nRestartSec=5\n\n[Install]\nWantedBy=multi-user.target

Секция [Unit] описывает метаданные и зависимости: Description задаёт человекочитаемое имя, видимое в выводе systemctl status, а After=network.target указывает, что сервис должен стартовать только после того, как сеть уже поднята, — актуально для любого приложения, обращающегося к внешним сервисам или базе данных сразу при старте.

Секция [Service] описывает, как именно запускать и контролировать сам процесс. ExecStart — обязательная директива с полным путём к исполняемому файлу и его аргументами; User задаёт, от имени какого системного пользователя выполняется процесс, что напрямую связано с правильной настройкой владельца файлов, к которым процесс обращается. Restart=on-failure вместе с RestartSec=5 указывает автоматически перезапускать процесс через 5 секунд после аварийного (не штатного) завершения, что делает сервис заметно устойчивее к временным сбоям без ручного вмешательства администратора.

Секция [Install] отвечает за то, к какой цели (target) привязывается сервис при использовании systemctl enable — multi-user.target соответствует обычному многопользовательскому режиму работы сервера без графического интерфейса, в который сервис на VPS попадает практически всегда.

Применение нового unit-файла: daemon-reload

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

systemctl daemon-reload\nsystemctl enable --now myapp\nsystemctl status myapp

Пропуск daemon-reload после правки unit-файла — частая причина недоумения, когда изменения в конфигурации сервиса как будто не действуют: systemctl restart в этом случае перезапустит процесс, но по-прежнему со старыми параметрами запуска, поскольку сам systemd ещё не в курсе, что файл на диске изменился. Явного предупреждения об этом системе может не выдать, поэтому daemon-reload стоит выполнять по привычке при каждой правке любого unit-файла, а не только когда что-то явно пошло не так.

После первого успешного запуска нового сервиса стоит сразу проверить его поведение при аварийном завершении, чтобы убедиться, что Restart=on-failure действительно работает так, как задумано, — например, вручную завершить процесс командой kill и посмотреть в journalctl, действительно ли systemd перезапустил его автоматически через заданный интервал, а не оставил лежать в состоянии failed.

systemd timers как основа для расписания

Помимо постоянно работающих сервисов, systemd умеет запускать задачи по расписанию через сочетание двух unit-файлов: .service, описывающего саму выполняемую команду (как обычный сервис, но с Type=oneshot вместо простого постоянного процесса), и .timer, задающего, когда именно этот сервис должен активироваться.

# /etc/systemd/system/backup.service\n[Unit]\nDescription=Резервное копирование базы данных\n\n[Service]\nType=oneshot\nExecStart=/usr/local/bin/backup.sh\n\n# /etc/systemd/system/backup.timer\n[Unit]\nDescription=Ежедневный запуск резервного копирования в 2:00\n\n[Timer]\nOnCalendar=*-*-* 02:00:00\nPersistent=true\n\n[Install]\nWantedBy=timers.target

Активировать нужно именно таймер, а не сам сервис напрямую, — сервис при этом остаётся неактивным между запусками и переходит в рабочее состояние только по сигналу от связанного таймера в назначенное время.

systemctl daemon-reload\nsystemctl enable --now backup.timer\nsystemctl list-timers

Параметр Persistent=true в секции [Timer] — заметное практическое преимущество systemd timers перед классическим cron: если сервер был выключен или перезагружался как раз в момент, когда должен был сработать таймер, задача с этим параметром выполнится сразу после следующего включения сервера, вместо того чтобы просто пропустить пропущенный запуск до следующего по расписанию, как это происходит с cron.

systemd timers против cron: когда что выбрать

Для большинства типичных серверных задач по расписанию — ежедневный бэкап, ротация логов, отправка отчётов — разница между cron и systemd timers на практике не критична, и оба механизма надёжно решают одну и ту же базовую задачу периодического выполнения команд. Подробный разбор синтаксиса и практических примеров cron дан в отдельной статье, посвящённой именно ему.

Ключевые практические преимущества systemd timers перед cron: встроенная интеграция с journalctl, благодаря которой вывод и ошибки задачи автоматически попадают в единый системный журнал без ручной настройки перенаправления, о котором приходится отдельно заботиться в cron; явные зависимости от других сервисов через директивы After и Requires, полезные, если задача не должна запускаться до готовности связанной службы, например базы данных; и уже упомянутая устойчивость к пропущенным запускам через Persistent=true.

Практические преимущества cron перед systemd timers: заметно более компактный синтаксис для простых случаев — одна строка вместо двух отдельных unit-файлов, привычность практически любому администратору Linux независимо от конкретного дистрибутива, и более простая процедура редактирования уже существующего расписания без необходимости выполнять daemon-reload после каждого изменения.

Разумный практический ориентир: для простых, некритичных периодических задач без сложных зависимостей от других сервисов cron остаётся более быстрым и привычным выбором; для задач, критичных к пропуску запуска (например, важных резервных копий на сервере, который иногда перезагружается в непредсказуемое время), или для задач, тесно связанных с состоянием других systemd-сервисов, стоит рассмотреть именно systemd timers, несмотря на более многословную настройку.

Типичные ошибки при работе с systemd

Забытый systemctl daemon-reload после изменения unit-файла — служба продолжает работать со старой конфигурацией, что легко принять за то, что внесённые изменения не действуют в принципе, хотя на самом деле они просто ещё не применены.

Использование systemctl start без предварительного или последующего enable в предположении, что служба продолжит запускаться автоматически после перезагрузки сервера, — start и enable решают независимые задачи, и для полноценной настройки на постоянную работу обычно нужны обе команды, а не одна из них.

Написание собственного unit-файла без указания User, из-за чего сервис по умолчанию запускается от имени root — избыточные привилегии для процесса, которому в подавляющем большинстве случаев не требуется полный доступ ко всей системе, что увеличивает потенциальный ущерб при обнаружении уязвимости именно в этом сервисе.

Отсутствие Restart=on-failure для сервисов, которые должны работать постоянно, — без этой директивы аварийное завершение процесса (например, из-за временной сетевой ошибки при обращении к внешнему API) оставляет сервис остановленным до ручного вмешательства администратора вместо автоматического восстановления работы.

Попытка отладить не запускающийся сервис исключительно через systemctl status без обращения к полному журналу через journalctl -u — краткий вывод status не всегда содержит достаточно контекста, особенно если проблема проявилась не в самой последней попытке запуска, а несколькими попытками раньше.

Чек-лист настройки собственного сервиса

Шаг 1. Определите, действительно ли задаче нужен постоянно работающий процесс (unit-файл сервиса) или достаточно периодического запуска по расписанию (cron или systemd timer с Type=oneshot) — это принципиально разные сценарии, требующие разной настройки.

Шаг 2. Создайте unit-файл в /etc/systemd/system с корректно заполненными ExecStart, User и WorkingDirectory, не оставляя пользователя по умолчанию равным root без явной необходимости.

Шаг 3. Добавьте Restart=on-failure и разумное значение RestartSec для сервисов, которые должны работать постоянно и автоматически восстанавливаться после сбоя.

Шаг 4. Выполните systemctl daemon-reload после создания или любого изменения unit-файла, прежде чем пытаться запустить или перезапустить сервис.

Шаг 5. Включите автозапуск и сразу запустите сервис командой systemctl enable --now, затем проверьте результат через systemctl status.

Шаг 6. Проверьте поведение сервиса при аварийном завершении вручную (kill процесса) и убедитесь через journalctl, что автоматический перезапуск действительно происходит так, как задумано в unit-файле.

Итог: единый инструмент для сервисов и расписаний

systemd и его основной инструмент управления systemctl закрывают практически весь спектр задач по управлению фоновыми процессами на современном Linux-сервере — от постоянно работающих служб вроде веб-сервера и базы данных до периодических задач через systemd timers, объединяя их под единым, предсказуемым набором команд независимо от конкретного дистрибутива.

Главные практические привычки, которые стоит унести из этой статьи: не забывать daemon-reload после правки unit-файлов, явно задавать пользователя и политику перезапуска для собственных сервисов вместо значений по умолчанию, и при диагностике неудачного запуска сразу обращаться к полному журналу через journalctl -u, а не ограничиваться кратким выводом status.

Если нужна помощь с оформлением собственного приложения или скрипта в виде управляемого systemd-сервиса, или с диагностикой уже возникшей проблемы с запуском конкретной службы на сервере — оставьте заявку внизу страницы, поможем настроить надёжный автозапуск и восстановление после сбоя под конкретный проект.