База знаний
Войти

Системный менеджер systemd

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

К основным задачам systemd относятся:

  • инициализация системы при запуске. systemd запускает все необходимые службы и процессы во время старта Системы;
  • управление всеми системными службами;
  • мониторинг состояния системы: сбор и предоставление информации о текущем состоянии всех служб и ресурсов системы;
  • управление зависимостями между службами, что гарантирует корректный порядок их запуска.

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

Под "сервисами" в контексте Системы и systemd понимаются службы (daemon), то есть компоненты, выполняющиеся в фоновом режиме и предоставляющие функциональность Системе или приложениям.

Сервисы описываются юнитом типа .service и управляются по жизненному циклу: запуск, остановка, перезапуск, перезагрузка конфигурации, проверка состояния.

Основные задачи systemd:

  • Инициализация Системы при загрузке и параллельный запуск необходимых компонентов;
  • Управление службами: запуск, остановка, перезапуск, загрузка конфигурации, контроль зависимостей и порядка инициализации;
  • Мониторинг состояния: определение статусов active, inactive, failed и др., автоматический перезапуск по политике;
  • Журналирование и диагностика: сбор логов через компонент journald и предоставление доступа к журналам;
  • Управление зависимостями и целями: формирование целевых состояний (targets), гарантия корректной последовательности запуска.

Все команды управления службами systemd выполняются через утилиту systemctl.

Для диагностики применяется просмотр журналов через journald; рекомендуется использовать подписанные и проверенные конфигурации юнитов и избегать ручного изменения файлов в /usr/lib/systemd/system, выполняя переопределения в /etc.

Управление службами

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

Основные команды по управлению сервисами в ОС:

  • Запуск сервиса:
sudo systemctl start <имя_сервиса>
  • Остановка сервиса:
sudo systemctl stop <имя_сервиса>
  • Перезапуск сервиса:
sudo systemctl restart <имя_сервиса>
  • Проверка статуса сервиса:
systemctl status <имя_сервиса>
  • Включение автозапуска сервиса при старте Системы:
sudo systemctl enable <имя_сервиса>
  • Отключение автозапуска сервиса при старте Системы:
sudo systemctl disable <имя_сервиса>
  • Перезагрузка с целью применения изменений конфигурации без перезапуска служб:
sudo systemctl reload <service_name>
  • Управление группами служб, например, можно запускать или останавливать группу служб:
sudo systemctl start <group_name>
sudo systemctl stop <group_name>

Фильтрация вывода systemctl возможна по различным критериям, таким как состояние службы с использованием опции --state или тип с использованием опции –type.

Unit-файлы

Unit-файлы являются основными конфигурационными файлами, которые используются в systemd для управления службами, монтированием файловых систем, сокетами и другими системными объектами. Именно они определяют, как и когда должны запускаться процессы, как обрабатывать их зависимости, и другие аспекты работы службы или ресурса.

Существуют различные типы unit-файлов:

  • service (расширение .service) – определяет параметры для управления службами;
  • target (расширение .target) – группирует несколько unit-файлов и управляет их совместным запуском;
  • socket (расширение .socket) – управляет сокетами, которые используются для активации служб;
  • mount (расширение .mount) – управляет точками монтирования файловых систем;
  • timer (расширение .timer) – предназначены для создания и управления таймерами, выполняют роль планировщика задач.

Unit-файлы имеют следующую базовую структуру:

  • Unit – описание метаданных и зависимостей;
  • Service / Timer (или другой секции в зависимости от типа unit-файла) – определяет параметры запуска и управления процессом;
  • Install – настройки, связанные с автозапуском и включением unit-файла в зависимости от системных целей (targets).

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

Алгоритм написания и настройки unit-файлов в systemd:

  1. Секция Unit `задает общие сведения о юните и его зависимости:
  • Description= – краткое описание юнита;
  • Wants= – указывает на необязательную зависимость: основной юнит пытается запустить другой юнит, указанный в параметре. Ошибки при запуске зависимого юнита не мешают запуску основного. Если параметры After= и Before= не указаны, юниты запускаются параллельно;
  • Requires= – обозначает обязательную зависимость: основной юнит требует запуск другого юнита. Если запуск зависимого юнита неудачен, основной юнит также не запустится. Без параметров After= и Before= оба юнита будут запущены одновременно;
  • After= – указывает, что основной юнит должен запускаться только после другого, указанного в параметре. Этот параметр часто используется вместе с Wants= и Requires=;
  • Before= – противоположен After=, определяет запуск основного юнита перед другим юнитом.
  1. Секция Install используется для настройки автозапуска юнита:
  • Alias= – позволяет задать дополнительные имена для юнита, при этом создаются символические ссылки на основной юнит. Поддерживается не всеми типами юнитов;
  • WantedBy= – указывает на цель, с которой связан данный юнит; при активации юнита команда systemctl enable создаст символическую ссылку в соответствующем каталоге;
  • Also= – перечисляет другие юниты, которые также будут добавлены в автозапуск или удалены из него при изменении состояния текущего юнита.
  1. Секция Service задает параметры управления службами:
  • Type= – определяет, как служба будет запускаться:
  • simple – запускает процесс немедленно, без создания дочерних процессов;
  • forking – запускает службу, которая создает дочерний процесс и завершает родительский. Часто используется для демонов;
  • oneshot – для одноразовых задач, которые завершаются после выполнения;
  • notify – аналогично simple, но с дополнительным уведомлением о готовности;
  • dbus – служба считается готовой, когда определенное имя появляется на шине D-Bus;
  • idle – откладывает запуск службы до завершения всех других задач;
  • PIDFile= – путь к PID-файлу;
  • WorkingDirectory= – рабочий каталог, в котором будет работать процесс;
  • User= – пользователь, от имени которого запускается служба;
  • Group= – группа, от имени которой запускается служба;
  • OOMScoreAdjust= – регулирует приоритет процесса при нехватке памяти;
  • ExecStop= – команда для остановки службы;
  • ExecStart= – команда, которая выполняется при запуске службы;
  • RemainAfterExit= – указывает, что служба считается активной даже после завершения.
  1. Секция Socket управляет параметрами сокетов:
  • ExecStart= – команда для запуска;
  • ExecReload= – команда для перезапуска;
  • KillMode= – режим завершения;
  • Restart= – правила перезапуска в случае ошибки.

Пример unit-файла службы:

[Unit]
Description=Пример службы
After=network.target

[Service]
ExecStart=/usr/bin/example-service
Restart=on-failure

[Install]
WantedBy=multi-user.target

где параметры:

  • Description= предоставляет краткое описание службы;
  • After= указывает, что служба должна быть запущена после достижения определенной цели (например, network.target);
  • ExecStart= определяет команду, которую необходимо выполнить для запуска службы;
  • Restart= управляет политикой перезапуска, в данном случае on-failure означает, что служба перезапустится при её сбое;
  • WantedBy= определяет, в каких режимах работы (targets) Система должна запускать эту службу.

Различные unit-файлы располагаются в следующих каталогах Системы:

  • /etc/systemd/system/ или /lib/systemd/system/ – для системных файлов. Файлы в этом каталоге имеют приоритет перед другими;
  • /usr/lib/systemd/system/ – для пользовательских unit-файлов;
  • /run/systemd/system/ – для временных unit-файлов, которые генерируются во время работы Системы.

Планирование задач с файлами .timer

Файлы с расширением .timer предназначены для создания и управления таймерами. В ОС они выполняют роль планировщика задач, являясь частью systemd и заменяя классический cron.

Файлы с расширением .timer работают в паре с .service-файлами, которые описывают действия, которые должны быть выполнены в запланированное время. Таймеры активируют определённые сервисы в моменты, заданные в конфигурации .timer-файла.

Файлы с расширением .timer имеют следующую основную структуру:

[Unit]
Description=Описание таймера
Requires=my.service #Запуск таймера, только при наличии соответствующего сервис файла “my.service”

[Timer]
OnCalendar=*-*-* 02:00:00 # Указание расписания (пример: каждый день в 2:00)
Persistent=true           # Выполнять задачу после пропуска, если Система была выключена
Unit=my.service  #Таймер, при срабатывании, запускает соответствующий сервис “my.service”

[Install]
WantedBy=timers.target     # Активирует файл .target если есть и запущен timers.target

Основные секции файла .timer

  1. Unit — стандартная секция для всех файлов systemd, содержит описание таймера:
  • Description — краткое описание цели таймера;
  • Requires= — запуск таймера произойдет только если существует соответствующий указанный сервис файл;
  1. Timer — основная секция, где задаются параметры работы таймера:
  • OnCalendar — задаёт расписание запуска (например, ежедневно, ежемесячно, по конкретным датам);
  • OnBootSec= — время после загрузки Системы (например, запуск через 5 минут после загрузки);
  • OnUnitActiveSec= — время после последнего запуска службы (например, через 10 минут после последнего выполнения).
  • Persistent= — если true, то задача будет выполнена сразу после включения Системы, если во время её выключения был пропущен запуск.
  • Unit= — данный параметр означает, что таймер, при срабатывании, запускает указанный сервис файл.
  1. Install — содержит информацию о том, как таймер должен быть активирован.
  • WantedBy= — если есть и запущен файл timers.target (который активирует все таймеры systemd), то активируется целевой .target файл и начинается отсчет времени таймера.

Элементы расписания OnCalendar

Значения параметра OnCalendar указывают на время или периодичность выполнения задания файла .service.

Формат параметра OnCalendar:

* *-*-* *:*:*
DayOfWeek Year-Month-Day Hour:Minute:Second

Этот формат можно комбинировать или опускать некоторые элементы. Синтаксис параметра поддерживает различные вариации, чтобы можно было точно настроить расписание.

Элементы расписания OnCalendar:

  • DayOfWeek — день недели (Sun, Mon, Tue, Wed, Thu, Fri, Sat).

Mon --* 02:00:00 — каждый понедельник в 2:00.

  • Year-Month-Day — год, месяц и день.

2024-10-01 — 1 октября 2024 года.

  • Использование символов подстановки: * — любая дата (например, --01 означает первый день каждого месяца).

Запись --* означает каждый день в любом году и месяце.

  • Hour:Minute — время в формате часов, минут и секунд.

14:30:00 — 14 часов 30 минут ровно.

Если нужно указать только часы и минуты, можно опустить секунды: 14:30.

Параметры опции OnCalendar:

  • Ежедневный запуск в полночь:
OnCalendar=daily
  • Еженедельный запуск (по умолчанию воскресенье в 0:00):
OnCalendar=weekly
  • Ежемесячный запуск (в полночь первого числа каждого месяца):
OnCalendar=monthly
  • Ежегодный запуск (первого января каждого года):
OnCalendar=yearly
  • или
OnCalendar=annually
  • Запуск каждый день в 2:00 ночи:
OnCalendar=*-*-* 02:00:00
  • Запуск по будням в 8:00 утра:
OnCalendar=Mon..Fri *-*-* 08:00:00
  • Запуск в первый день каждого месяца ровно в полночь:
OnCalendar=*-*-01 00:00:00
  • Запуск каждый год в конкретный день (например, 25 декабря каждого года):
OnCalendar=*-12-25 00:00:00
  • Запуск раз в час:
OnCalendar=hourly
  • Запуск каждые 15 минут:
OnCalendar=*:00/15

Если таймер содержит опцию Persistent=true, это означает, что, если Система была выключена в момент времени, когда задача должна была запуститься, она будет выполнена сразу после следующего включения. Это полезно для гарантий выполнения важных задач.

systemd позволяет комбинировать параметры настроек. Например:

OnCalendar=Mon *-*-* 03,15:00:00

Здесь задается запуск задачи каждый понедельник в 3:00 и 15:00.

Чтобы проверить правильность работы таймера, можно использовать команду:

systemctl list-timers

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

Работа таймеров с файлами .service

Для работы таймеров необходимо создать соответствующий файл WantedBy=multi-user.target.service, который описывает, что должно выполняться, когда таймер срабатывает.

Файл .timer определяет расписание запуска.

Файл .service определяет, что нужно выполнить по этому расписанию.

Таймер запускает указанный сервис в момент времени, заданный в .timer файле.

Для примера рассмотрим файл .service для выполнения задачи резервного копирования:

[Unit]
Description=Задача резервного копирования
Wants=my.timer

[Service]
Type=oneshot
ExecStart=/usr/bin/rsync -av /home/ /mnt/backup

[Install]
WantedBy=multi-user.target

где:

  • Параметр Wants=my.timer указывает, что необходимый сервис запустится и будет в режиме ожидания если запущен и работает таймер "my.timer".
  • Параметр WantedBy=multi-user.target указывает, на каком уровне загрузки Системы будет работать данный сервис.

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

  • Запуск таймера вручную:
sudo systemctl start backup.timer
  • Активация таймера при запуске Системы:
sudo systemctl enable backup.timer
  • Проверка статуса таймера:
systemctl status backup.timer
  • Просмотр всех активных таймеров:
systemctl list-timers

Состояние Системы

Состояние Системы и набор загружаемых сервисов определяется целями (targets) systemd. Цели (targets) systemd представляют собой группы служб и юнитов, которые должны быть активированы в определенных состояниях Системы.

Основные цели systemd:

  • poweroff.target – используется для полного отключения Системы.
  • rescue.target – вводит Систему в однопользовательский режим для диагностики и восстановления. Этот режим предназначен для выполнения административных задач, доступных только для root.
  • multi-user.target – полный многопользовательский режим с поддержкой сети. Эта цель запускает текстовый интерфейс, и большинство серверов работают именно в этом режиме.
  • graphical.target – запускает Систему в многопользовательском режиме с графическим интерфейсом (GUI). Этот режим используется на настольных системах.
  • reboot.target – перезагружает Систему.

Помимо стандартных целей, systemd включает и другие специализированные цели:

  • emergency.target – самый минималистичный режим с доступом только к корневой консоли. Используется для восстановления в критических ситуациях.
  • halt.target – останавливает Систему без полного выключения (зависает на экране "halt").
  • suspend.target, hibernate.target, hybrid-sleep.target – Эти цели управляют различными состояниями энергосбережения, такими как приостановка (suspend), гибернация (hibernate) и гибридный сон.

Цели (targets) в systemd определены в виде файлов с расширением .target. Системные файлы .target расположены в каталоге /lib/systemd/system/ или /etc/systemd/system/ и отвечают за запуск Системы в указанном состоянии. Пользовательские файлы .target хранятся в /usr/lib/systemd/user/.

Переключаться между целями можно с помощью команды:

sudo systemctl isolate <цель>

Например, чтобы перевести Систему в графический режим:

sudo ystemctl isolate graphical.target

Чтобы просмотреть активную цель:

sudo systemctl get-default

systemd-resolved

systemd-resolved — системная служба, предназначенная для разрешения сетевых имён, входящая в состав пакета systemd. Служба обеспечивает поддержку различных протоколов разрешения имён, включая:

  • традиционную систему доменных имён (DNS), в том числе DNSSEC и DNS over TLS;
  • Multicast DNS (mDNS);
  • Link-Local Multicast Name Resolution (LLMNR).

Поддерживаемые режимы работы

Служба systemd-resolved может функционировать в одном из четырёх режимов. Наиболее часто применяются следующие два:

  • Работа через DNS-заглушку systemd (рекомендуемый режим): в этом режиме используется локальный адрес 127.0.0.53 в качестве единственного DNS-сервера. Необходимо создать символическую ссылку:
ln -sf /run/systemd/resolve/stub-resolv.conf\ /etc/resolv.conf

Это обеспечивает корректную работу всех процессов с использованием systemd-resolved.

  • Работа с прямым использованием файла /etc/resolv.conf: в этом режиме служба использует указанный файл напрямую, как обычный DNS-клиент. Подходит для ситуаций, когда требуется сохранить совместимость с устаревшими приложениями.

Режим работы определяется автоматически, в зависимости от содержимого или назначения символической ссылки /etc/resolv.conf.

Для получения сведений о текущих настройках systemd-resolved, включая активные DNS-серверы, используется команда:

resolvectl status

Служба работает автоматически с сетевыми менеджерами, использующими файл /etc/resolv.conf, в том числе с systemd-networkd и NetworkManager. При этом DNS-серверы передаются службе systemd-resolved автоматически.

При необходимости можно вручную задать параметры DNS-серверов и fallback-серверов в файле /etc/systemd/resolved.conf. Пример настройки:

[Resolve]
DNS=192.168.35.1 fd7b:d0bd:7a6e::1
FallbackDNS=208.67.222.222 208.67.220.220

В случае отсутствия информации от сетевого менеджера и при неуказанных вручную серверах служба использует зарезервированные DNS-адреса (например, Яндекс 77.88.8.8, Google 8.8.8.8).

Управление службой systemd-resolved:

  • перезапуск службы:
sudo systemctl restart systemd-resolved.service
  • остановка службы:
sudo systemctl stop systemd-resolved.service

По умолчанию служба systemd-resolved включена и активна.

Конфликт порта 53 при использовании systemd-resolved

Служба systemd-resolved по умолчанию использует порт 53 (протокол DNS) на локальном интерфейсе 127.0.0.53 для организации локальной DNS-заглушки. В случае установки и запуска на том же узле стороннего DNS-сервера (например, named в составе BIND), также предназначенного для работы на порту 53, возникает конфликт ресурсов: обе службы не могут одновременно прослушивать один и тот же порт.

Подобная ситуация характерна, в частности, при настройке контроллера домена Samba с использованием внешнего DNS-сервера. Для предотвращения конфликта требуется отключить использование порта 53 службой systemd-resolved.

Для отключения порта 53 необходимо выполнить следующие действия:

  1. Создать каталог для дополнительной конфигурации службы:
mkdir -p /etc/systemd/resolved.conf.d
  1. Создать в нём файл с настройкой, отключающей локальную DNS-заглушку:
echo -e '[Resolve]\nDNSStubListener=no' >\ /etc/systemd/resolved.conf.d/no53port.conf
  1. Перезапустить службу systemd-resolved, чтобы применить изменения:
sudo systemctl try-restart systemd-resolved

После выполнения указанных действий служба systemd-resolved прекращает использовать порт 53, что позволяет другим компонентам (например, named) корректно его задействовать.