Коротко о главном
systemd управляет службами, монтированием, таймерами и журналами. Многие администраторы используют только systemctl, но понимание юнитов и зависимостей позволяет диагностировать запуск и делать собственные сервисы.
Юниты описывают, как запускать приложение, от кого зависит и что делать при сбое. Таймеры заменяют cron с лучшим логированием, а journalctl даёт структурированные логи.
systemd — инструмент, который стоит освоить, если вы регулярно работаете в Linux. Ниже — путь от установки до уверенной повседневной работы: без предположений, что всё уже настроено само.
Зачем нужен systemd
systemd решает вполне конкретные задачи: Юниты, таймеры, зависимости и журналирование в современном Linux. Важно не превращать инструмент в самоцель — если задача проще решается штатными средствами системы, начните с них.
Установка
В Debian, Ubuntu и Linux Mint используется пакетный менеджер APT:
sudo apt install systemd
В Fedora и RHEL-совместимых системах пакет ставится через DNF:
sudo dnf install systemd
В Arch Linux и производных пакет доступен в официальных репозиториях:
sudo pacman -S systemd
Пошаговая настройка
После установки переходите к базовому сценарию. Команды ниже выполняйте от пользователя с достаточными правами, но не запускайте всё под root без необходимости.
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
Базовая конфигурация
Начните с минимального рабочего варианта. Не копируйте большой конфиг целиком: добавляйте параметры по одному и проверяйте результат после каждого изменения.
[Unit]
Description=My backup job
After=network-online.target
[Service]
Type=oneshot
ExecStart=/usr/local/bin/backup.sh
Практические советы
Эти рекомендации проверены на повседневных задачах. Начните с тех, которые закрывают вашу текущую боль, а не со всего списка сразу.
Совет 1. Не запускайте сервисы от root без необходимости.
Не запускайте сервисы от root без необходимости.
Совет 2. Используйте Restart=on-failure с задержкой.
Используйте Restart=on-failure с задержкой.
Совет 3. Настройте лимиты памяти и файловых дескрипторов.
Настройте лимиты памяти и файловых дескрипторов.
Совет 4. Для длинных задач используйте Type=oneshot и таймер.
Для длинных задач используйте Type=oneshot и таймер.
Совет 5. Храните юниты в Git и разворачивайте через Ansible.
Храните юниты в Git и разворачивайте через Ansible.
Практический сценарий
Представьте типовую задачу: нужно развернуть systemd на одной машине, проверить работу и передать доступ коллеге. Начните с чистой системы или снапшота, чтобы результат был воспроизводим. Запишите все команды в отдельный файл — это одновременно шпаргалка и черновик будущей автоматизации.
Дальше действуйте короткими шагами: установка, минимальная конфигурация, проверка, затем расширение. После каждого шага фиксируйте, что именно изменилось и как это проверить. Такой журнал экономит время, когда через месяц понадобится повторить настройку на другом сервере или объяснить её коллеге.
Порядок работ для этого сценария выглядит так:
- Создайте service-юнит
- Проверьте синтаксис и запустите
- Добавьте таймер
- Смотрите журналы
- Разберите зависимости
Отдельно продумайте, что произойдёт при сбое. Для systemd важно заранее знать, где хранятся данные, как их скопировать и сколько времени займёт восстановление. Если ответа нет, не двигайтесь дальше: сначала закройте этот пробел, потом добавляйте новые возможности.
Типичные ошибки
Ниже — сбои, которые встречаются чаще всего. Перед исправлением сохраните текущие конфиги и запишите, какие изменения вносите: так проще откатиться.
1. Unit not found
Проверьте имя файла, daemon-reload и путь. systemctl cat покажет, какой файл используется.
2. Сервис падает сразу после старта
Смотрите journalctl -u и код выхода. Часто виноваты права, отсутствующий каталог или неверный ExecStart.
3. Таймер не срабатывает
Проверьте systemctl list-timers, Persistent и время. Убедитесь, что таймер включён, а не только запущен.
Что проверить перед вводом в работу
Перед тем как считать настройку завершённой, пройдитесь по короткому списку. Он не заменяет полноценный аудит, но отсекает большинство очевидных проблем.
Чек-лист
- Версия systemd зафиксирована, а обновления не применяются вслепую.
- Есть резервная копия конфигурации и данных, восстановление проверено.
- Доступ ограничен нужными пользователями и сетями, лишние порты закрыты.
- Логи и метрики собираются, понятно, куда смотреть при сбое.
- Изменения описаны в документации и могут быть повторены на другой машине.
- Есть план отката и понятный критерий, по которому вы решите его применить.
Если какой-то пункт вызывает затруднение, это сигнал вернуться к соответствующему разделу, а не откладывать проверку. Настройка, которую нельзя повторить, плохо работает не только у коллег, но и у вас самих через полгода.
Итог
systemd — это не «поставил и забыл». Рабочая конфигурация складывается из понимания задачи, аккуратной установки и проверки результата. Начните с базового сценария, затем добавляйте только те возможности, которые действительно используете.