Каталог .d рядом с юнитом: как systemd склеивает конфигурацию сервиса и где ломается ExecStart

Знакомая ситуация: в юнит сервиса аккуратно вписана нужная строка, всё работает, а после очередного апдейта сервис ведёт себя так, будто правки не было. Так и есть — файл переписан установщиком. У Xray это /etc/systemd/system/xray.service, и разработчики честно оставили предупреждение внутри своего же вспомогательного файла: «Or all changes you made will be lost!». С юнитом Docker, приезжающим из пакета, произойдёт ровно то же самое.

Копировать чужой юнит к себе и жить с копией — плохая стратегия: апстрим будет чинить свой файл, а у вас останется снимок двухлетней давности, о расхождении вы узнаете случайно. В systemd для этого предусмотрен отдельный механизм — drop-in, крошечный .conf, который меняет только интересующие вас строки.

Из чего складывается конфигурация сервиса

Разобрав основной файл foo.service, менеджер идёт в одноимённый каталог foo.service.d/ и дочитывает оттуда всё, что оканчивается на .conf. Таких каталогов система знает три, и вес у них разный — от пакетного к пользовательскому: /usr/lib/systemd/system/, затем /run/systemd/system/, затем /etc/systemd/system/. Формулировка из systemd.unit(5): «Drop-in files in /etc/ take precedence over those in /run/ which in turn take precedence over those in /usr/lib/».

А вот дальше начинается то, что регулярно упускают. Каталог не решает, кто применится позже: сортировка идёт по имени файла — «Multiple drop-in files with different names are applied in lexicographic order, regardless of which of the directories they reside in». Отсюда практическое следствие: файл override.conf из-под systemctl edit окажется поверх установочного 10-donot_touch_single_conf.conf, потому что в ASCII цифра меньше буквы.

Случай первый: прокси для докерового демона

Файл ~/.docker/config.json демону не указ — он смотрит на переменные окружения собственного процесса. Поэтому в документации Docker описан именно drop-in:

sudo mkdir -p /etc/systemd/system/docker.service.d
sudo tee /etc/systemd/system/docker.service.d/http-proxy.conf >/dev/null <<'EOF'
[Service]
Environment="HTTP_PROXY=http://proxy.example.com:3128"
Environment="HTTPS_PROXY=http://proxy.example.com:3128"
Environment="NO_PROXY=localhost,127.0.0.1,.corp"
EOF
sudo systemctl daemon-reload
sudo systemctl restart docker

Убедиться в результате помогает systemctl show --property=Environment docker — ожидаемый ответ содержит все три пары в одной строке. Ничего не вывелось? Либо промахнулись каталогом, либо забыли про daemon-reload. Rootless-инсталляции работают по тому же принципу, но каталог лежит в домашней директории — ~/.config/systemd/user/docker.service.d/, а sudo меняется на флаг --user.

Случай второй: другая команда запуска и пустая строка перед ней

На этом месте спотыкаются чаще всего. Директива ExecStart= относится к накапливающимся: ваша строка не вытеснит исходную, а встанет рядом с ней. При этом в systemd.service(5) записано жёсткое условие — «Unless Type= is oneshot, exactly one command must be given». Для обычного сервиса второй команды достаточно, чтобы юнит отказался загружаться.

Лечится это обнулением списка перед новым значением, что документация подтверждает прямо: «If the empty string is assigned to this option, the list of commands to start is reset». Выглядит так:

[Service]
ExecStart=
ExecStart=/usr/local/bin/xray run -confdir /usr/local/etc/xray/

Ровно этот приём использует и сам установщик Xray в своём drop-in — сперва пустое присваивание, следом рабочая команда. Правило универсально: ExecStartPre=, Environment=, After= ведут себя точно так же.

Случай третий: лимиты и рестарт — обнуление не требуется

Такие директивы одиночные, побеждает последнее присвоенное значение.

sudo systemctl edit --drop-in=90-limits.conf xray.service

[Service]
LimitNOFILE=1048576
Restart=always
RestartSec=5

Отдельная команда перезагрузки после systemctl edit не нужна: выход из редактора уже делает действие, «equivalent to systemctl daemon-reload». Смотреть при этом стоит не в файл, а на то, что получил менеджер: systemctl show -p LimitNOFILE -p Restart xray.service. Кстати, применительно к Xray дескрипторы трогать смысла мало — установщик и так задаёт LimitNOFILE=1000000 вместе с LimitNPROC=10000; куда чаще правят Restart=on-failure, переводя его в always.

Есть ещё режим, о котором вспоминают редко, — флаг --runtime. Изменение записывается в /run/systemd/system/ и живёт до перезагрузки. Пригодится, когда сервис нужно на полчаса перевести в Restart=no и при этом ничего после себя не оставить.

Источники

• systemd.unit(5) — каталоги drop-in, приоритет и лексикографический порядок
• systemd.service(5) — сброс ExecStart= пустым присваиванием
• systemctl(1) — edit, --drop-in=, --runtime, revert, cat
• Docker Docs: Configure the daemon to use a proxy
• XTLS/Xray-install: install-release.sh