Обновить
8

Пользователь

2,1
Рейтинг
5
Подписчики
Отправить сообщение

Что нам стоит override для юнита systemd написать? Подумал я как-то пятничным вечером, да чего там, я 100 раз так делал, 5 минут и справимся. Но не тут-то было, в посте хочу разобрать основные ошибки создания override.

Для начала немного теории - зачем он нужен. Как правило такая потребность возникает в сценариях:

  • автор ОС/пакета предусмотрел плохие дефолты или не подходящие для вас. классический пример PrivateTmp=Yes для exim или чего-то похожего

  • вам хочется дополнить/исправить логику работы демона, например очистить кэш, перегенерировать какой-то uuid перед стартом

  • юнит начал много кушать сокетов/памяти и вам хочется расширить-зарезать оные персонально этому юниту. зачастую плохая идея зарезать для определенного класса софта

  • да зачем нужен override, я просто внесу нужные изменения в юнит? нужен, потому что при любом обновлении dnf/apt системный пакет перетрет ваши изменения и вы очень долго будете искать потом что сломалось

Итак, основные ошибки при созданию override файлов:

  • мы все любим в deb based дистрибутивах цветовую схему nano по-умолчанию, прочитать блеклый текст между каких строк нужно писать я с первого раза не смог

    писать надо строго по стрелочке, а не расскоментировать пример
    писать надо строго по стрелочке, а не расскоментировать пример
  • писать нужно включая секцию, но это я помнил и так, пример

### Editing /etc/systemd/system/ssh.service.d/override.conf
### Anything between here and the comment below will become the contents of the drop-in file

[Service]
ExecStartPre=

### Edits below this comment will be discarded
  • у systemd нет шелла. совсем. поэтому пайпы, редиректы и все что связано не работают
    пример нерабочего оверрайда
    [Service]
    ExecStartPre=/usr/bin/uuidgen > /tmp/123
    пример правильного
    [Service]
    ExecStartPre=/bin/sh -c "/usr/bin/uuidgen > /tmp/123"

    без прямого указания шелла у вас uuidgen будет просто выплевываться в journalctl

После правки изменения нужно сохранить и сказать systemctl daemon-reload. Проверить внесенные изменения можно systemctl cat unitname, что не очень наглядно, лучше использовать systemctl status unitname будет виден результирующий юнитфайл.

Надеюсь сэкономил вам несколько минут.

Теги:
0
Комментарии0

Информация

В рейтинге
1 705-й
Зарегистрирован
Активность