Как правильно редактировать юниты systemd
Сегодня systemd стал безальтернативной системой управления службами в дистрибутивах первого эшелона и предоставил администраторам простые и удобные возможности для решения этой задачи.
Действительно, сравните сложность написания init-файла и юнита. 🤷🏻♀️
И, как всякая хорошо спроектированная и продуманная система systemd предполагает многоуровневую систему управления юнитами.
Начнем с мест их расположения, которые перечислим в порядке повышения приоритета:
▫️ /usr/lib/systemd/system – юниты установленные вместе с пакетами
▫️ /run/systemd/system – юниты, которые создаются автоматически при загрузке системы и существующие только в рамках текущего сеанса
▫️ /etc/systemd/system – юниты, созданные системным администратором
Директория /etc/systemd/system имеет наивысший приоритет и если нам нужно изменить существующий юнит службы, то мы можем скопировать его сюда из /usr/lib/systemd/system и внести свои изменения.
Вроде бы просто, да не совсем. При обновлении пакета юнит в /usr/lib/systemd/system тоже будет обновляться, при этом, в отличии от изменения конфигурационных файлов, никакого предупреждения мы не получим.
Юнит пакета будет жить сам по себе, и наш, скопированный юнит тоже сам по себе. Но применяться, в силу приоритета, будет именно наш юнит.
К чему это может привести? Да к чему угодно и отловить причину внезапно возникшего непонятного поведения службы может быть достаточно проблематично.
Особенно критично это может быть при обновлении системы на новую версию, где исходный юнит службы может подвергнуться серьезным изменениям.
Как быть? К счастью, в systemd, как в хорошо спроектированной системе, есть возможность точечно вносить изменения в конфигурацию юнита при помощи технологии drop-in.
Скажем, нам нужно внести изменения в работу юнита myservice.service, для этого мы должны создать каталог /etc/systemd/system/ myservice.service.d и поместить в него один или несколько фалов с расширением conf.
Проще всего это сделать с помощью команды:
systemctl edit myservice
Напоминаем, что если вы не указали тип юнита, то по умолчанию он принимается за service, а если вам нужно внести изменения в таймер, то придется указать имя юнита полностью:
systemctl edit myservice.timer
Затем указываем только те опции, которые хотим переопределить или добавить, например:
[Unit]
Requires=новая зависимость
After=новая зависимость
Для опций, предполагающих множественные значения следует предварительно выполнить их сброс, иначе переопределяемое значение будет добавлено к уже существующему в файле юнита. К таким опциям относятся ExecStart или OnCalendar в таймерах.
Если вы добавите:
[Service]
ExecStart=новая команда
То эта строка будет добавлена к существующим строкам ExecStart в юните, если вы хотите переопределить это значение, то его сначала необходимо сбросить:
[Service]
ExecStart=
ExecStart=новая команда
Если у вас несколько Drop-in файлов, то изменения в них будут применяться по очереди, для расстановки приоритетов можете использовать цифровые префиксы файлов.
Еще одним достоинством команды systemctl edit является то, что по окончании редактирования конфигурация systemd будет перечитана, а служба перезапущена.
Откатить изменения можно командой
systemctl revert myservice
Если вы редактируете drop-in файлы вручную, то после каждого изменения перечитайте конфигурацию:
systemctl daemon-reload
И перезапустите службу
systemctl restart myservice
Как видим, systemd дает в руки администратора серьезные инструменты позволяющие точечно редактировать конфигурацию юнитов.
Мы рекомендуем использовать данный подход даже для внесения изменения в собственные юниты, так откатить изменения в drop-in файле проще, чем восстановить исходное состояние конфигурации службы.
