Поверхностный мониторинг показывал: сервис active, порт слушает, аварии нет. На деле daemon стартовал с root после ручной правки unit-файла, а ожидаемый User=daemon применялся только в забытом drop-in. После обновления пакета правка исчезла, но systemd не сообщил ничего подозрительного: процесс был жив. Диагностика начинается с фактической сборки юнита: systemctl cat app.service; systemctl show app.service -p FragmentPath -p DropInPaths -p User -p Group -p ExecStart; systemd-delta. После изменения нужен systemctl daemon-reload, затем явный restart. daemon-reload сам процесс не перезапускает. Проверка границы ядра: pid=$(systemctl show -p MainPID --value app.service); awk '/Uid|Gid|CapEff|NoNewPrivs|Seccomp/ {print}' /proc/$pid/status; cat /proc/$pid/limits; systemd-analyze security app.service. Так видно реальный UID, capability mask и ограничения процесса, а не декларацию в репозитории. Журнал ищется через journalctl -u app.service -b. Правильная схема: базовый unit принадлежит пакету, override лежит в /etc/systemd/system/app.service.d/override.conf и доставляется конфигурационным управлением с проверяемым diff. Ручная правка допустима только как аварийная диагностика, после которой изменение либо фиксируется, либо удаляется. Разбор: https://ftops.space/?utm*source=telegram&utm*medium=smm&utm*campaign=ftops&utm*content=systemd-drop-in-overrides-vs-ruchnye