systemd: как это работает под капотом

Коротко о главном

systemd управляет службами, монтированием, таймерами и журналами. Многие администраторы используют только systemctl, но понимание юнитов и зависимостей позволяет диагностировать запуск и делать собственные сервисы.

Юниты описывают, как запускать приложение, от кого зависит и что делать при сбое. Таймеры заменяют cron с лучшим логированием, а journalctl даёт структурированные логи.

Чтобы уверенно пользоваться systemd, полезно понимать, как он устроен внутри. Разберём ключевые компоненты, конфигурацию и диагностику — без пересказа документации.

Как это устроено

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

Юниты описывают, как запускать приложение, от кого зависит и что делать при сбое. Таймеры заменяют cron с лучшим логированием, а journalctl даёт структурированные логи. Именно поэтому настройка через переменные окружения и конфигурационные файлы предпочтительнее ручных правок «на месте».

Разбор конфигурации

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

[Unit]
Description=My backup job
After=network-online.target

[Service]
Type=oneshot
ExecStart=/usr/local/bin/backup.sh

Ключевые компоненты и их взаимодействие

1. Создайте service-юнит

Файл кладите в /etc/systemd/system. Описывайте абсолютные пути и пользователя, от которого работает сервис.

sudo systemctl edit --full --force myapp.service

2. Проверьте синтаксис и запустите

Используйте daemon-reload после изменения юнита. status показывает последние логи и код выхода.

sudo systemctl daemon-reload
sudo systemctl enable --now myapp.service
systemctl status myapp.service

3. Добавьте таймер

Таймер запускает oneshot-сервис по расписанию. Не смешивайте расписание и саму задачу в одном юните.

[Timer]
OnCalendar=daily
Persistent=true

[Install]
WantedBy=timers.target

4. Смотрите журналы

journalctl фильтрует по юниту, времени и приоритету. Для live-режима используйте -f.

journalctl -u myapp.service -n 100 --no-pager
journalctl -u myapp.service -f

5. Разберите зависимости

Если сервис не стартует, проверьте, какие юниты он требует и что мешает запуску.

systemctl list-dependencies myapp.service
systemd-analyze verify /etc/systemd/system/myapp.service

Диагностика и тонкая настройка

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

Практические советы

Эти рекомендации проверены на повседневных задачах. Начните с тех, которые закрывают вашу текущую боль, а не со всего списка сразу.

Совет 1. Не запускайте сервисы от root без необходимости.

Не запускайте сервисы от root без необходимости.

Совет 2. Используйте Restart=on-failure с задержкой.

Используйте Restart=on-failure с задержкой.

Совет 3. Настройте лимиты памяти и файловых дескрипторов.

Настройте лимиты памяти и файловых дескрипторов.

Совет 4. Для длинных задач используйте Type=oneshot и таймер.

Для длинных задач используйте Type=oneshot и таймер.

Совет 5. Храните юниты в Git и разворачивайте через Ansible.

Храните юниты в Git и разворачивайте через Ansible.

Типичные ошибки

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

1. Unit not found

Проверьте имя файла, daemon-reload и путь. systemctl cat покажет, какой файл используется.

2. Сервис падает сразу после старта

Смотрите journalctl -u и код выхода. Часто виноваты права, отсутствующий каталог или неверный ExecStart.

3. Таймер не срабатывает

Проверьте systemctl list-timers, Persistent и время. Убедитесь, что таймер включён, а не только запущен.

Что улучшить после базовой настройки

Когда systemd работает предсказуемо, следующий шаг — наблюдаемость. Добавьте проверку состояния, которая отвечает на вопрос «жив ли сервис», и метрику, показывающую нагрузку. Без этого вы узнаёте о проблеме от пользователей, а не от системы.

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

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

Итог

Понимание внутреннего устройства systemd экономит часы диагностики. Когда знаете, где хранится состояние и как компоненты общаются, ошибка перестаёт быть «магией».