0Pricing
Linux Command Line & Bash Scripting Mastery · Урок

Управление службами systemd и создание файлов модулей

Управляйте службами через systemctl и создавайте пользовательские файлы модулей и таймеров для демонов, запускаемых скриптами

«Управление службами systemd и создание файлов модулей» — бесплатный урок Linux Command Line & Bash Scripting Mastery на CoddyKit. Это урок 2 из 4. Ты можешь прочитать весь урок бесплатно ниже — а потом практиковать его прямо в браузере с встроенным редактором кода и ИИ-репетитором 24/7. Это часть пути обучения Linux Command Line & Bash Scripting Mastery, и твой прогресс синхронизируется между веб-версией и приложением CoddyKit. Курс Linux Command Line & Bash Scripting Mastery содержит 4 уроков всего.

Введение в systemd и systemctl

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

Основной инструмент взаимодействия с systemd — systemctl. С его помощью Вы можете:

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

Все службы, управляемые systemd, определяются с помощью файлов юнитов — декларативных конфигурационных файлов, хранящихся в /etc/systemd/system/ (для всей системы) или ~/.config/systemd/user/ (для отдельного пользователя).

Основные команды systemctl

Это наиболее часто используемые команды systemctl для повседневного управления службами. Каждая команда работает с именем модуля, например nginx.service или просто nginx.

  • systemctl start <unit> — немедленно запустить службу
  • systemctl stop <unit> — остановить работающую службу
  • systemctl restart <unit> — остановить, а затем запустить службу (полный перезапуск)
  • systemctl reload <unit> — отправить SIGHUP для перезагрузки конфигурации без остановки службы
  • systemctl enable <unit> — создать символические ссылки, чтобы модуль запускался при загрузке системы
  • systemctl disable <unit> — удалить эти символические ссылки
  • systemctl status <unit> — показать состояние, PID и последние строки журнала
#!/usr/bin/env bash
# Quick reference: inspect and control an nginx service
# (Requires nginx to be installed; run as root or with sudo)

systemctl status nginx
systemctl start nginx
systemctl enable nginx
systemctl reload nginx
systemctl restart nginx
systemctl stop nginx
systemctl disable nginx

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

systemctl status выводит подробную информацию о модуле. Понимание этого вывода необходимо для быстрой диагностики проблем.

  • Loaded: путь к файлу модуля и информация о том, включён ли он при загрузке системы
  • Active: текущее состояние — active (running), inactive (dead), failed
  • Main PID: идентификатор процесса, являющегося главным процессом службы
  • CGroup: все дочерние процессы, относящиеся к службе
  • Log lines: самые последние записи журнала для этого модуля

Также можно отдельно запросить состояние активности с помощью systemctl is-active, а состояние включения — с помощью systemctl is-enabled. Эти команды особенно удобны для использования в сценариях.

#!/usr/bin/env bash
# Script-friendly service health check
SERVICE="sshd"

if systemctl is-active --quiet "$SERVICE"; then
    echo "$SERVICE is running."
else
    echo "$SERVICE is NOT running. Attempting restart..."
    systemctl restart "$SERVICE"
fi

if systemctl is-enabled --quiet "$SERVICE"; then
    echo "$SERVICE is enabled at boot."
else
    echo "WARNING: $SERVICE is not enabled at boot."
fi

Просмотр и фильтрация модулей

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

Полезные параметры фильтрации:

  • --type=service — показывать только модули служб
  • --state=failed — показывать только модули с ошибками
  • --state=active — показывать только активные модули
  • --all — включать в список неактивные модули

Сочетание этих фильтров с grep позволяет создавать мощные конвейеры проверки в сценариях обслуживания.

#!/usr/bin/env bash
# List all failed services and report them
echo "=== Failed Services ==="
systemctl list-units --type=service --state=failed --no-legend

echo ""
echo "=== Services Enabled at Boot ==="
systemctl list-unit-files --type=service --state=enabled --no-legend | awk '{print $1}'

Устройство файла модуля службы systemd

Файл модуля службы — это обычный текстовый файл в формате INI, состоящий из разделов. Каждый раздел управляет отдельным аспектом жизненного цикла модуля.

  • [Unit] — метаданные: описание и зависимости порядка запуска (After=, Requires=, Wants=)
  • [Service] — способы запуска и остановки процесса: ExecStart, ExecStop, Restart, User, WorkingDirectory
  • [Install] — условия включения этого модуля: WantedBy=multi-user.target означает, что он активируется при обычной многопользовательской загрузке

После размещения или редактирования файла модуля в каталоге /etc/systemd/system/ необходимо выполнить systemctl daemon-reload, чтобы systemd применил изменения.

Создание первого файла модуля службы

Создадим простой файл модуля службы для пользовательского сценария Python HTTP-сервера. Этот файл сообщает systemd, как именно управлять данным процессом, словно это обычная системная служба.

Основные директивы [Service], используемые здесь:

  • Type=simple — systemd считает процесс ExecStart главным процессом
  • User=www-data — запускать процесс от непривилегированной учётной записи для повышения безопасности
  • WorkingDirectory — задать рабочий каталог процесса
  • Restart=on-failure — автоматически перезапускать процесс, если он завершился с ненулевым кодом
  • RestartSec=5 — ждать 5 секунд между попытками перезапуска
#!/usr/bin/env bash
# Create a custom service unit file for a simple HTTP server
# Run as root

cat > /etc/systemd/system/mywebserver.service << 'EOF'
[Unit]
Description=My Custom Python Web Server
After=network.target

[Service]
Type=simple
User=www-data
WorkingDirectory=/var/www/mysite
ExecStart=/usr/bin/python3 -m http.server 8080
Restart=on-failure
RestartSec=5
StandardOutput=journal
StandardError=journal

[Install]
WantedBy=multi-user.target
EOF

systemctl daemon-reload
systemctl enable --now mywebserver.service
systemctl status mywebserver.service

Типы служб и жизненный цикл процессов

Директива Type= в разделе [Service] сообщает systemd, как определить момент завершения запуска службы. Неправильный выбор типа часто приводит к ошибкам в порядке запуска.

  • Type=simple — используется по умолчанию; systemd считает службу запущенной сразу после запуска ExecStart. Сигнал готовности не требуется.
  • Type=forking — процесс ExecStart создаёт дочерний процесс и завершается, а настоящий фоновый процесс работает как дочерний. Используйте PIDFile=, чтобы systemd мог отслеживать его.
  • Type=notify — процесс отправляет sd_notify(READY=1), когда действительно готов к работе. Это наиболее надёжный вариант для сложных фоновых процессов.
  • Type=oneshot — запускается один раз и завершается; последующие модули ожидают завершения. Идеально подходит для сценариев настройки.
  • Type=idle — подобен simple, но выполнение откладывается до завершения всех активных заданий.
#!/usr/bin/env bash
# Example: oneshot service for a database migration script
# /etc/systemd/system/db-migrate.service

cat > /etc/systemd/system/db-migrate.service << 'EOF'
[Unit]
Description=Run Database Migrations
After=postgresql.service
Requires=postgresql.service

[Service]
Type=oneshot
User=appuser
WorkingDirectory=/opt/myapp
ExecStart=/opt/myapp/scripts/migrate.sh
RemainAfterExit=yes

[Install]
WantedBy=multi-user.target
EOF

systemctl daemon-reload
systemctl start db-migrate.service

Переменные окружения и усиление безопасности

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

Директивы окружения:

  • Environment="KEY=value" — задать одну переменную непосредственно в файле
  • EnvironmentFile=/etc/myapp/env — загрузить переменные из файла (по одной записи KEY=value в строке)

Распространённые директивы усиления безопасности:

  • NoNewPrivileges=true — запретить процессу получать дополнительные привилегии через setuid
  • ProtectSystem=strict — подключить /usr, /boot и /etc только для чтения
  • PrivateTmp=true — предоставить службе собственный изолированный каталог /tmp
  • CapabilityBoundingSet= — отключить все возможности Linux
#!/usr/bin/env bash
# Hardened service unit with environment file

cat > /etc/systemd/system/secureapp.service << 'EOF'
[Unit]
Description=Secure Application Daemon
After=network.target

[Service]
Type=simple
User=secureapp
Group=secureapp
WorkingDirectory=/opt/secureapp
EnvironmentFile=/etc/secureapp/env
ExecStart=/opt/secureapp/bin/server
Restart=on-failure
RestartSec=10

# Security hardening
NoNewPrivileges=true
ProtectSystem=strict
ProtectHome=true
PrivateTmp=true
CapabilityBoundingSet=
ReadWritePaths=/var/lib/secureapp /var/log/secureapp

[Install]
WantedBy=multi-user.target
EOF

# Create the environment file separately so secrets stay out of the unit file
install -m 600 -o secureapp /dev/null /etc/secureapp/env
echo 'APP_PORT=9000' >> /etc/secureapp/env
echo 'DB_URL=postgresql://localhost/mydb' >> /etc/secureapp/env

systemctl daemon-reload

Введение в модули таймеров systemd

Таймер systemd — это модуль, который запускает другой модуль (обычно .service) по расписанию. Он заменяет традиционные задания cron более интегрированным механизмом, поддерживающим журналирование и управление.

Каждому модулю таймера (foo.timer) соответствует модуль службы с тем же базовым именем (foo.service), выполняющий фактическую работу. Включать и запускать нужно таймер, а не службу напрямую.

Типы таймеров:

  • Таймеры реального времени (календарные) — срабатывают в заданное время по часам с использованием выражений OnCalendar=, таких как daily, weekly или Mon *-*-* 02:00:00
  • Монотонные таймеры — срабатывают относительно события в системе с использованием OnBootSec=, OnActiveSec= или OnUnitActiveSec=

Создание файла модуля таймера

Создадим полноценную пару «таймер + служба», которая запускает сценарий резервного копирования каждый день в 02:00. Обратите внимание: раздел [Timer] находится в отдельном файле .timer, а выполняемая работа описывается в соответствующем файле .service.

Основные директивы [Timer]:

  • OnCalendar= — календарное выражение для расписания
  • Persistent=true — если в момент срабатывания таймера система была выключена, выполнить задачу сразу после следующей загрузки
  • RandomizedDelaySec= — добавить случайную задержку до N секунд, чтобы предотвратить одновременный запуск множества узлов по одному расписанию
  • Unit= — явно указать целевой модуль (необязательно, если имена совпадают)
#!/usr/bin/env bash
# Create a daily backup timer pair
# Run as root

# 1. The service that does the work
cat > /etc/systemd/system/daily-backup.service << 'EOF'
[Unit]
Description=Daily Database Backup
After=network.target postgresql.service

[Service]
Type=oneshot
User=backup
ExecStart=/usr/local/bin/backup-db.sh
StandardOutput=journal
StandardError=journal
EOF

# 2. The timer that schedules it
cat > /etc/systemd/system/daily-backup.timer << 'EOF'
[Unit]
Description=Run Daily Database Backup at 02:00

[Timer]
OnCalendar=*-*-* 02:00:00
Persistent=true
RandomizedDelaySec=300

[Install]
WantedBy=timers.target
EOF

systemctl daemon-reload
systemctl enable --now daily-backup.timer

# Verify
systemctl list-timers daily-backup.timer

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

systemd направляет весь вывод служб в журнал, который можно запрашивать с помощью journalctl. Это объединяет журналы всех модулей в одном хранилище с возможностью поиска.

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

  • -u <unit> — фильтровать по имени модуля
  • -f — отслеживать журнал в реальном времени (как tail -f)
  • -n 50 — показывать только последние 50 строк
  • --since "1 hour ago" — ограничить вывод по времени
  • -p err — показывать только записи с приоритетом «ошибка» и выше
  • -b — показывать журналы только текущей загрузки

Если модуль не запускается, сначала выполните journalctl -u <unit> -n 30 --no-pager, а затем systemctl status <unit>, чтобы получить контекст последних ошибок.

#!/usr/bin/env bash
# Troubleshooting helper: dump unit status and recent logs
# Usage: ./service-debug.sh <unit-name>

UNIT="${1:-nginx.service}"

echo "=============================="
echo "STATUS: $UNIT"
echo "=============================="
systemctl status "$UNIT" --no-pager -l

echo ""
echo "=============================="
echo "RECENT LOGS (last 50 lines): $UNIT"
echo "=============================="
journalctl -u "$UNIT" -n 50 --no-pager

echo ""
echo "=============================="
echo "ERRORS ONLY (current boot)"
echo "=============================="
journalctl -u "$UNIT" -b -p err --no-pager

Проверка знаний: файлы модулей systemd

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

Итоги урока: управление службами systemd и создание файлов модулей

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

  • Основы systemctl — запуск, остановка, перезапуск, перезагрузка, включение, отключение, проверка состояния, активности и включения служб с помощью команд, удобных для сценариев
  • Просмотр и фильтрация — использование list-units и list-unit-files с параметрами --type и --state для отбора служб с ошибками или включённых служб
  • Устройство файла модуля — три раздела [Unit], [Service] и [Install] и их основные директивы
  • Типы служб — simple, forking, notify, oneshot и случаи использования каждого типа
  • Окружение и безопасность — EnvironmentFile, NoNewPrivileges, ProtectSystem и PrivateTmp для защищённых фоновых процессов
  • Модули таймеров — объединение файлов .timer и .service, выражения OnCalendar и поведение догоняющего запуска с помощью Persistent
  • Journalctl — фильтрация по модулю, времени, загрузке и приоритету для эффективной диагностики сбоев

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

Часто задаваемые вопросы

Урок «Управление службами systemd и создание файлов модулей» бесплатный?

Да — полный текст урока «Управление службами systemd и создание файлов модулей» бесплатно доступен здесь в веб-версии. Чтобы практиковать его интерактивно (встроенный редактор кода и ИИ-репетитор 24/7) и разблокировать остальной курс Linux Command Line & Bash Scripting Mastery, подпишись на CoddyKit PRO. Курс Linux Command Line & Bash Scripting Mastery содержит 4 уроков всего.

Чему я научусь в уроке «Управление службами systemd и создание файлов модулей»?

Управляйте службами через systemctl и создавайте пользовательские файлы модулей и таймеров для демонов, запускаемых скриптами Ты практикуешь Linux Command Line & Bash Scripting Mastery с помощью реального кода, который запускаешь прямо в браузере, и ИИ-репетитор 24/7 отвечает на твои вопросы во время урока.

Нужен ли мне опыт, чтобы начать Linux Command Line & Bash Scripting Mastery?

Предыдущий опыт не требуется. Linux Command Line & Bash Scripting Mastery на CoddyKit структурирован для всех уровней — от новичков до продвинутых, поэтому ты можешь начать отсюда или с самого начала и учиться в своем темпе. Это урок 2 из 4.

Сколько времени занимает урок «Управление службами systemd и создание файлов модулей»?

Большинство уроков CoddyKit занимают около 5–10 минут. Каждый из них компактный и интерактивный, поэтому ты постоянно делаешь прогресс и продолжаешь с того же места в веб-версии и приложении.

Можно ли писать и запускать код в этом уроке Linux Command Line & Bash Scripting Mastery?

Да. Каждый урок Linux Command Line & Bash Scripting Mastery включает встроенный редактор кода, поэтому ты пишешь и запускаешь реальный код прямо в браузере и получаешь моментальную обратную связь от AI — локальная установка не требуется.

Все уроки этого курса

  1. Автоматизация создания пользователей и групп
  2. Управление службами systemd и создание файлов модулей
  3. Автоматизация дисков, файловых систем и монтирования
  4. Создание скриптов проверки состояния системы и оповещений
← Назад к Linux Command Line & Bash Scripting Mastery