SystemdDoctor
мешает работе частое конфигурация drop-in

Переопределение через drop-in не применяется

Переопределения лежат в каталоге вида /etc/systemd/system/myapp.service.d/*.conf и дополняют основной файл. Если правка не действует, причин обычно три: не перечитана конфигурация, файл назван неверно, либо параметр требует предварительного сброса.

Что это значит

Особенность, из-за которой теряют больше всего времени: параметры со списком значений (ExecStart=, Environment=, After=) в переопределении добавляются к существующим, а не заменяют их. Чтобы заменить, нужно сначала очистить значение пустой строкой.

Вероятные причины

По порядку: сверху то, что встречается чаще.

  1. Не выполнена перезагрузка конфигурации

    Файлы переопределений читаются так же, как основной unit: изменения на диске сами по себе ничего не меняют.

  2. Файл переопределения назван неверно

    systemd читает в каталоге .d только файлы с расширением .conf. Файл override или 10-override.conf.bak будет проигнорирован.

  3. Параметр со списком не сброшен перед заменой

    Для ExecStart= в обычной службе это приводит к ошибке «service has more than one ExecStart», а для списков зависимостей — к добавлению вместо замены.

  4. Переопределение попало не в тот unit

    Каталог должен называться точно по имени unit, включая расширение: myapp.service.d, а не myapp.d. Для шаблонных unit есть свои правила именования.

Диагностика

Команды идут в том порядке, в котором их стоит выполнять: каждая следующая проверяет то, что осталось после предыдущей.

Печатает основной файл и все применённые переопределения с путями. Если вашего файла тут нет, он не читается.

systemctl cat myapp.service

Итоговые значения после слияния: видно, заменилось значение или добавилось.

systemctl show myapp.service -p ExecStart -p Environment -p After

Показывает все переопределения в системе и что именно они меняют.

sudo systemd-delta --type=extended | head -20

Решение

Решение своё для каждой причины. Сначала определите, какая из них ваша, — иначе правки наложатся друг на друга.

1. Не выполнена перезагрузка конфигурации
Почему происходит
Файлы переопределений читаются так же, как основной unit: изменения на диске сами по себе ничего не меняют.
Как проверить
Посмотрите, нужна ли перезагрузка, и что systemd считает действующим. 
systemctl show myapp.service -p NeedDaemonReload
systemctl cat myapp.service
Как исправить
Выполните перезагрузку конфигурации и перезапустите службу. 
sudo systemctl daemon-reload && sudo systemctl restart myapp.service
2. Файл переопределения назван неверно
Почему происходит
systemd читает в каталоге .d только файлы с расширением .conf. Файл override или 10-override.conf.bak будет проигнорирован.
Как проверить
Посмотрите содержимое каталога. 
sudo ls -l /etc/systemd/system/myapp.service.d/
Как исправить
Переименуйте файл так, чтобы он заканчивался на .conf. Удобнее не создавать файлы вручную, а пользоваться systemctl edit.
3. Параметр со списком не сброшен перед заменой
Почему происходит
Для ExecStart= в обычной службе это приводит к ошибке «service has more than one ExecStart», а для списков зависимостей — к добавлению вместо замены.
Как проверить
Посмотрите итоговое значение параметра. 
systemctl show myapp.service -p ExecStart -p After
Как исправить
Сначала очистите значение пустым присваиванием, затем задайте новое. 
[Service]
ExecStart=
ExecStart=/usr/local/bin/myapp --new-flag
4. Переопределение попало не в тот unit
Почему происходит
Каталог должен называться точно по имени unit, включая расширение: myapp.service.d, а не myapp.d. Для шаблонных unit есть свои правила именования.
Как проверить
Сверьте имя каталога с именем unit. 
systemctl cat myapp.service | head -3
sudo ls -d /etc/systemd/system/*.d
Как исправить
Переименуйте каталог. Для шаблона правка применяется либо к myapp@.service.d (всем экземплярам), либо к myapp@prod.service.d (одному).

Пример вывода

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

$ sudo systemctl restart myapp.service
Job for myapp.service failed because the control process exited with error code.

systemd[1]: /etc/systemd/system/myapp.service.d/override.conf:2: Service has more than one ExecStart= setting, which is only allowed for Type=oneshot services. Refusing.
systemd[1]: myapp.service: Unit configuration has fatal error, unit will not be started.

Связанные ошибки

Источники

  • systemd.unit(5)
    Каталоги *.d, порядок слияния и сброс списочных параметров пустым присваиванием.     официальная документация, systemd 255
    сверено 15 сентября 2026
  • systemd-delta(1)
    Просмотр переопределений в системе.     официальная документация, systemd 255
    сверено 15 сентября 2026
  • Воспроизведено на тестовой машине, systemd 255 (Ubuntu 24.04)
    Воспроизведено переопределением с двумя ExecStart и файлом без расширения .conf.     собственная проверка, systemd 255
    сверено 15 сентября 2026