Управление службами в Linux с помощью systemd

Введение

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

В этой статье рассмотрим основы работы с systemd, научимся управлять службами, анализировать ошибки и создавать собственные сервисы.

Что такое systemd

systemd - это система инициализации (init system), которая запускается одной из первых после загрузки ядра Linux и отвечает за запуск остальных служб и компонентов системы.

До появления systemd многие дистрибутивы использовали SysVinit, однако он имел ряд ограничений:

• медленная последовательная загрузка;
• сложное управление зависимостями;
• ограниченные возможности мониторинга процессов.

Systemd решает эти проблемы и предоставляет единый интерфейс управления системой.

Проверить используется ли systemd можно командой:

ps -p 1

Пример вывода:

Если процесс с PID 1 называется systemd, значит система использует именно его.

Что такое служба (service)

Служба - это процесс, работающий в фоновом режиме.

Например:

• SSH-сервер;
• веб-сервер Apache или Nginx;
• база данных MySQL или PostgreSQL;
• Docker;
• мониторинг Zabbix Agent.

Systemd управляет такими службами через специальные файлы конфигурации, называемые unit-файлами.

Обычно они имеют расширение:

.service

Например:

• ssh.service
• nginx.service
• docker.service

Просмотр состояния службы

Самая полезная команда:

systemctl status ssh

или

systemctl status ssh.service

Пример:

Основные параметры:

Параметр	Значение
Loaded	служба найдена и загружена
Active	текущее состояние
Main PID	основной процесс
Memory	используемая память
Tasks	количество процессов

Если служба работает:

Active: active (running)

Если остановлена:

Active: inactive (dead)

Если произошла ошибка:

Active: failed

Запуск службы

Для запуска используется:

systemctl start nginx

После запуска проверяем:

systemctl status nginx

Остановка службы

Для остановки:

systemctl stop nginx

После выполнения веб-сервер перестанет принимать подключения.

Перезапуск службы

Часто используется после изменения конфигурации.

systemctl restart nginx

Пример:

Изменили файл:

/etc/nginx/nginx.conf

После этого выполняем:

systemctl restart nginx

Новая конфигурация вступит в силу.

Перезагрузка конфигурации без остановки службы

Некоторые сервисы поддерживают мягкую перезагрузку:

systemctl reload nginx

В этом случае:

• соединения не разрываются;
• процессы не перезапускаются полностью;
• применяется новая конфигурация.

Проверить поддержку можно командой:

systemctl status nginx

или

systemctl show nginx | grep ExecReload

Проверка включена ли служба в автозагрузку

Команда:

systemctl is-enabled nginx

Возможные варианты:

enabled

Служба запускается автоматически.

disabled

Автозапуск отключён.

Включение автозагрузки

Чтобы сервис запускался после каждой перезагрузки:

systemctl enable nginx

Пример вывода:

Created symlink ...

Теперь сужба будет стартовать автоматически.

Отключение автозагрузки

systemctl disable nginx

После перезагрузки сервис запускаться не будет.

Одновременный запуск и добавление в автозагрузку

Очень удобная команда:

systemctl enable --now nginx

Она сразу:

• запускает службу;
• включает автозагрузку.

Обратный вариант:

systemctl disable --now nginx

Просмотр всех служб

Показать все службы:

systemctl list-units --type=service

Только активные:

systemctl list-units --type=service --state=running

Только завершившиеся ошибкой:

systemctl --failed

Пример:

Поиск проблемных служб

Одна из первых команд при диагностике:

systemctl --failed

Например:

Получаем подробности:

systemctl status nginx.service

Из лога можем понять, что ошибка случилась в файле конфигурации nginx.

Просмотр логов службы

Systemd тесно интегрирован с журналом событий. Посмотреть логи службы:

journalctl -u nginx

Последние записи:

journalctl -u nginx -n 50

Просмотр в реальном времени:

journalctl -u nginx -f

Аналогично:

tail -f

но напрямую через системный журнал.

Просмотр логов после последнего запуска

Очень полезно после аварийного завершения:

journalctl -u nginx -b

Только ошибки:

journalctl -p err

Критические ошибки:

journalctl -p crit

Где находятся unit-файлы

Чаще всего:

/usr/lib/systemd/system/

или

/lib/systemd/system/

Для пользовательских настроек:

/etc/systemd/system/

Проверить расположение:

systemctl cat nginx

Изучаем unit-файл

Пример:

Разбор содержимого nginx.service

Секция [Unit]

• Description= - краткое описание службы, отображается в выводе systemctl status.
• Documentation= - ссылка на документацию или man-страницу службы.
• After= - определяет порядок запуска. Nginx будет запускаться после указанных целей и служб.
• Wants= - мягкая зависимость. Systemd попытается запустить указанную цель, но её ошибка не помешает запуску nginx.
• ConditionFileIsExecutable= - проверяет существование файла и наличие права на выполнение перед запуском службы.

Секция [Service]

• Type=forking - указывает, что приложение после запуска уходит в фон и создаёт дочерний процесс.
• PIDFile= - путь к файлу с PID основного процесса, который systemd использует для контроля службы.
• ExecStartPre= - команда, выполняемая перед запуском службы. В данном случае проверяет корректность конфигурации nginx.
• ExecStart= - основная команда запуска службы.
• ExecReload= - команда перечитывания конфигурации без полной остановки службы.
• ExecStop= - команда корректной остановки nginx через отправку сигнала SIGQUIT.
• TimeoutStopSec= - время ожидания завершения службы после выполнения команды остановки.
• KillMode=mixed - определяет порядок принудительного завершения процессов службы, если штатная остановка не удалась.

Разбор команд запуска и остановки

• nginx -t - проверка конфигурации nginx на наличие ошибок.
• -q - тихий режим проверки, выводятся только ошибки.
• daemon on - запуск nginx в фоновом режиме.
• master_process on - включение master-процесса nginx, управляющего worker-процессами.
• nginx -s reload - перечитывание конфигурации без остановки веб-сервера.
• QUIT/5 - отправка сигнала SIGQUIT и ожидание завершения процесса в течение 5 секунд.

Секция [Install]

• WantedBy=multi-user.target - определяет, что служба должна запускаться в обычном многопользовательском режиме системы.
• При выполнении systemctl enable nginx создаётся символическая ссылка, благодаря которой nginx автоматически запускается после загрузки системы.

Что происходит при запуске nginx через systemd

1. Проверяется наличие файла /usr/sbin/nginx.
2. Ожидается готовность сети.
3. Выполняется проверка конфигурации командой nginx -t.
4. При успешной проверке запускается nginx.
5. Systemd получает PID процесса из файла /run/nginx.pid.
6. Начинается мониторинг службы.
7. Состояние службы можно проверить через systemctl status nginx.
8. Журнал работы доступен через journalctl -u nginx.

Создаём собственную службу

Предположим есть скрипт:

/opt/telegram-bot/bot.py

Создаём unit-файл:

nano /etc/systemd/system/telegram-bot.service

Содержимое:

[Unit]
Description=Telegram Notification Bot
After=network.target

[Service]
Type=simple
User=root
WorkingDirectory=/opt/telegram-bot
ExecStart=/usr/bin/python3 bot.py
Restart=always

[Install]
WantedBy=multi-user.target

Сохраняем файл.

Рассмотрим назначение каждого параметра.

Секция [Unit]

• Description=Telegram Notification Bot - описание службы. Отображается в выводе команды systemctl status.
• After=network.target - запускать службу после инициализации сетевого стека. Это важно для Telegram-бота, так как для работы ему требуется доступ к сети.

Секция [Service]

• Type=simple - самый распространённый тип службы для современных приложений. Systemd считает службу запущенной сразу после выполнения команды из ExecStart.
• User=root - указывает пользователя, от имени которого будет запущен процесс. В данном примере бот запускается с правами суперпользователя.
• WorkingDirectory=/opt/telegram-bot - рабочая директория приложения. Перед запуском systemd выполнит переход в этот каталог.
• ExecStart=/usr/bin/python3 bot.py - команда запуска службы. В данном случае systemd запускает интерпретатор Python и передаёт ему файл bot.py.
• Restart=always - автоматически перезапускать службу при любом завершении процесса, независимо от причины остановки.

Секция [Install]

• WantedBy=multi-user.target - запускать службу в обычном многопользовательском режиме Linux. Именно благодаря этому параметру команда systemctl enable добавляет сервис в автозагрузку.

Обновляем конфигурацию systemd

После создания нового сервиса обязательно выполняем:

systemctl daemon-reload

Иначе systemd не увидит новый unit-файл.

Запускаем созданную службу

systemctl start telegram-bot

Проверяем:

systemctl status telegram-bot

Включаем автозагрузку:

systemctl enable telegram-bot

Что делать если служба не запускается

Проверяем состояние:

systemctl status telegram-bot

Смотрим журнал:

journalctl -u telegram-bot -n 100

Очень часто причина одна из следующих:

• неправильный путь к скрипту;
• отсутствуют права на выполнение;
• неверный пользователь;
• отсутствует рабочая директория;
• ошибка внутри самого приложения.
  

Автоматический перезапуск после сбоя

Для большинства собственных сервисов рекомендуется:

Restart=on-failure
RestartSec=5

Пример:

[Service]
ExecStart=/usr/bin/python3 bot.py
Restart=on-failure
RestartSec=5

Если приложение аварийно завершится, через 5 секунд оно будет запущено снова.

Проверка времени загрузки системы

Systemd позволяет быстро узнать, что замедляет запуск сервера.

Общее время загрузки:

systemd-analyze

Пример:

Самые медленные службы:

systemd-analyze blame

Пример:

Сразу видно, что именно тормозит загрузку системы.

Полезные команды systemd

Команда	Назначение
systemctl status service	Проверка состояния
systemctl start service	Запуск
systemctl stop service	Остановка
systemctl restart service	Перезапуск
systemctl reload service	Перечитать конфигурацию
systemctl enable service	Автозагрузка
systemctl disable service	Отключить автозагрузку
systemctl --failed	Ошибки служб
journalctl -u service	Просмотр логов
systemd-analyze blame	Анализ загрузки

Заключение

Systemd давно стал стандартом де-факто для большинства Linux-дистрибутивов. Даже базовое знание команд systemctl и journalctl значительно упрощает администрирование серверов, поиск неисправностей и управление приложениями.

Для начинающего администратора достаточно освоить запуск, остановку, перезапуск служб, работу с автозагрузкой и просмотр журналов. Этих навыков хватит для обслуживания большинства серверов с Linux. А в дальнейшем можно перейти к более продвинутым возможностям systemd - таймерам, пользовательским службам, ограничениям ресурсов и автоматизации задач.