Иногда открываешь unit-файл и не находишь параметр, который явно влияет на работу сервиса.
Причина в том, что systemd собирает конфигурацию не только из основного файла.
Смотрим итоговую конфигурациюsystemctl cat nginx.service
Команда покажет основной unit и применённые drop-in конфигурации.
Например:
/etc/systemd/system/nginx.service
/etc/systemd/system/nginx.service.d/override.conf
И в
override.conf может находиться:[Service]
LimitNOFILE=65535
Environment="APP_ENV=prod"
Хотя в самом
nginx.service этих параметров вообще нет.Находим все локальные измененияsystemd-delta
Она показывает unit-файлы, которые отличаются от поставленных системой, включая override.
Для конкретного сервиса:
systemd-delta nginx.service
Проверяем, что systemd реально применилsystemctl show nginx.service \
-p LimitNOFILE \
-p Environment \
-p FragmentPath \
-p DropInPaths
Здесь уже отображается эффективное состояние запущенного unit, а не просто содержимое файла
Почему это важноНа production сервере сервис может вести себя иначе после локального override
Например, основной unit говорит:
User=nginx
а drop-in меняет:
[Service]User=appИ если смотреть только основной файл, причина изменения останется незаметной.
При странном поведении systemd-сервиса полезно разделять две вещи: что написано в unit-файле и какую конфигурацию PID 1 реально применил. systemctl cat, systemd-delta и systemctl show позволяют увидеть эту разницу
