Systemd Services: Полное руководство по управлению службами Linux

Введение / Зачем это нужно

Systemd — это современная система инициализации и менеджер служб для большинства Linux-дистрибутивов (Ubuntu, Debian, CentOS, Fedora). Понимание systemd services критически важно для администрирования серверов, настройки автоматизации и диагностики проблем.

После прохождения этого гайда вы сможете:

• Управлять встроенными и пользовательскими службами через systemctl
• Читать и анализировать логи через journalctl
• Создавать, включать и отключать службы
• Диагностировать типичные ошибки запуска

Требования / Подготовка

1. Операционная система: Linux с systemd (проверьте: pidof systemd должен вернуть PID).
2. Права доступа: Для управления системными службами требуются права root (используйте sudo).
3. Базовые знания: Умение работать с терминалом, редактировать файлы (nano/vim), понимать структуру каталогов Linux.
4. Рекомендуемые утилиты: systemctl, journalctl, cat, less, grep (все предустановлены).

Основные команды для управления службами

Systemctl — основной инструмент взаимодействия с systemd. Вот ключевые операции:

Просмотр списка служб

# Все активные службы
systemctl list-units --type=service --state=running

# Все службы (включая неактивные)
systemctl list-unit-files --type=service

# Фильтрация по имени
systemctl list-units --type=service | grep nginx

Управление состоянием службы

# Запуск/остановка/перезагрузка
sudo systemctl start имя_службы.service
sudo systemctl stop имя_службы.service
sudo systemctl restart имя_службы.service

# Перезагрузка с reread конфигов (без остановки)
sudo systemctl reload имя_службы.service

# Проверка статуса
systemctl status имя_службы.service

💡 Совет: Имя службы можно не указывать с расширением .service — systemd добавит его автоматически: systemctl status nginx вместо nginx.service.

Просмотр логов служб (journalctl)

Systemd хранит логи в бинарном журнале, доступном через journalctl.

Основые сценарии использования

# Логи конкретной службы
sudo journalctl -u nginx.service

# Логи за последний час
sudo journalctl -u nginx.service --since "1 hour ago"

# Отслеживание в реальном времени (как tail -f)
sudo journalctl -u nginx.service -f

# Фильтрация по приоритету (err, warning, info)
sudo journalctl -u nginx.service -p err

# Логи с момента последней перезагрузки
sudo journalctl -u nginx.service -b

# Очистка журнала (если занял много места)
sudo journalctl --vacuum-time=3d  # оставить логи за 3 дня

Поиск проблем

# Найти ошибки в логах всех служб
sudo journalctl -p err --since today

# Показать последние 50 строк лога nginx
sudo journalctl -u nginx -n 50

# Экспорт логов в файл
sudo journalctl -u nginx > nginx_logs.txt

Создание собственной службы systemd

Давайте создадим службу для запуска пользовательского скрипта.

Шаг 1: Подготовьте скрипт

Создайте скрипт, который будет выполняться. Пример: /opt/myscript.sh

#!/bin/bash
# Пример скрипта, который пишет в лог каждую минуту
LOG_FILE="/var/log/myscript.log"
echo "$(date): myscript запущен" >> $LOG_FILE

Дайте права на выполнение:

sudo chmod +x /opt/myscript.sh

Шаг 2: Создайте unit-файл

Создайте файл /etc/systemd/system/myscript.service:

[Unit]
Description=Моя пользовательская служба
After=network.target

[Service]
Type=simple
ExecStart=/opt/myscript.sh
Restart=on-failure
RestartSec=10
User=root
Group=root

[Install]
WantedBy=multi-user.target

Объяснение параметров:

• After=network.target — запуск после сети.
• Type=simple (по умолчанию) — процесс запускается напрямую.
• Restart=on-failure — перезапускать при падении.
• RestartSec=10 — ждать 10 секунд перед перезапуском.
• WantedBy=multi-user.target — цель для автозагрузки (многопользовательский режим).

Шаг 3: Активируйте службу

# Перезагрузить конфигурацию systemd
sudo systemctl daemon-reload

# Запустить сейчас
sudo systemctl start myscript.service

# Включить на автозагрузку
sudo systemctl enable myscript.service

# Проверить статус
systemctl status myscript.service

Шаг 4: Проверьте работу

# Логи службы
sudo journalctl -u myscript.service -f

# Файл, который создаёт скрипт
sudo cat /var/log/myscript.log

Управление автозагрузкой и зависимостями

Цели (targets) systemd

Аналог runlevels в SysVinit:

• multi-user.target — многопользовательский режим (без GUI).
• graphical.target — с графическим интерфейсом.
• rescue.target — аварийный режим.

Узнайте текущую цель:

systemctl get-default

Измените цель (например, переключиться в графический режим):

sudo systemctl set-default graphical.target

Зависимости между службами

В секции [Unit] можно указать:

Requires=nginx.service    # Требует запуска nginx
After=nginx.service       # Запускать после nginx
Wants=nginx.service       # Желательно запустить nginx (необязательно)

Пример для веб-приложения, зависящего от базы данных:

[Unit]
Description=My Web App
Requires=postgresql.service
After=postgresql.service

Проверка результата

1. Статус службы: systemctl status имя_службы должен показывать active (running).
2. Автозагрузка: systemctl is-enabled имя_службы → enabled.
3. Логи: journalctl -u имя_службы не содержит ошибок Failed или timeout.
4. Процесс: ps aux | grep имя_скрипта показывает запущенный процесс.
5. Функциональность: Если служба предоставляет сервис (веб-сервер, БД), проверьте его доступность (например, curl http://localhost).

Возможные проблемы

1. Служба не запускается: systemctl start молчалив

• Причина: Ошибка в unit-файле или скрипте.
• Решение: Проверьте journalctl -u служба -b и systemctl status служба. Частые ошибки:
  • Неправильный путь в ExecStart (используйте абсолютный путь).
  • Нет прав на скрипт (chmod +x).
  • Порт уже занят (для сетевых служб).

2. Служба запускается, но сразу падает

• Причина: Скрипт завершается с ошибкой.
• Решение: Добавьте Type=oneshot + RemainAfterExit=yes для одноразовых задач, или убедитесь, что скрипт не завершается (демонизируйте его). Проверьте переменные окружения — systemd может не передавать PATH.

3. Ошибка permissions при создании unit-файла

• Причина: Файл создан не от root или с неправильными правами.
• Решение:

  sudo chown root:root /etc/systemd/system/*.service
  sudo chmod 644 /etc/systemd/system/*.service
  

4. Логи journalctl пустые для службы

• Причина: Служба не пишет в stdout/stderr, или используется syslog вместо journald.
• Решение: Убедитесь, что скрипт выводит в консоль (echo, print). Если используется внешний логгер (например, nginx пишет в /var/log/nginx), смотрите его логи напрямую.

5. Зависимости не срабатывают

• Причина: Некорректный target в WantedBy/Requires.
• Решение: Проверьте существование цели: systemctl list-units --type=target. Используйте multi-user.target для фоновых служб, graphical.target для GUI-приложений.

6. Служба не включается на автозагрузку

• Причина: Отсутствует секция [Install] с WantedBy.
• Решение: Добавьте в unit-файл:

  [Install]
  WantedBy=multi-user.target
  

  Затем sudo systemctl daemon-reload && sudo systemctl enable служба.

Дополнительные ресурсы

• Man-страницы: man systemd, man systemctl, man systemd.unit, man journalctl.
• Официальная документация: https://www.freedesktop.org/wiki/Software/systemd/
• Диагностика: sudo systemd-analyze blame — посмотреть, какие службы грузятся долго.
• Редактирование существующих служб: /lib/systemd/system/ (пакетные) vs /etc/systemd/system/ (локальные). Изменяйте только в /etc/, чтобы обновления пакетов не затерли настройки.

Systemd — мощный инструмент. Экспериментируйте с тестовыми службами, изучайте логи и gradually усложняйте конфигурации. Удачи в администрировании!