Поверхностный мониторинг показывал: сервис 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 принадлежи...

Поверхностный мониторинг показывал: сервис active, порт слушает, аварии нет. На деле daemon стартовал с root после ручной правки unit-файла, а ожидаемый User=daemon применялся только в забытом drop-in | Сетка — социальная сеть от hh.ru