先看现象。CentOS 7 上把 /usr/lib/systemd/system/app.service 里的 User 改成 app，daemon-reload 加 restart 之后 ps 里还是 root，systemctl cat 一打出来，User 出现了两次，中间试过重装服务包也没用。
把日志和配置对完，能解释这个现象的基本就这几处。/etc/systemd/system/app.service.d/ 里的 drop-in 也写了 User=root，它的优先级高于主文件。也可能是改的是 /usr/lib 下由 rpm 管理的文件，下次升级会被覆盖回去。
另外，只改了文件没 daemon-reload，systemd 内存里还是旧 unit。
动手时先看合并后的最终内容
systemctl cat app接着找出所有覆盖来源
ls /etc/systemd/system/app.service.d/ && grep -rn 'User=' /etc/systemd/system/再往下用官方位置写覆盖
systemctl edit app 里写 [Service] User=app剩下的就是重载并验证进程属主
systemctl daemon-reload && systemctl restart app && ps -o user,cmd -C app这次没动代码，只在配置和运行环境上找原因。
隔了一天再看，现象没变，说明不是偶发。
那几天正好在做别的变更，先把时间线对齐才敢动手。
怎么算真的好了，看的是同一批现象。systemctl show app -p User 返回 app，ps 里进程属主是 app，日志中不再出现 Permission denied。
提醒一点。同一个键写两次是排查 systemd 问题的第一嫌疑，systemctl cat 比看源文件可靠；改动一律放 /etc 下，别碰 /usr/lib。线上能稳定复现的问题都不算难，难的是只在大流量下才出现的那种。