Ubuntu 20.04 上调整了服务的内存限制和日志级别，改完 /etc/systemd/system/api.service 执行 systemctl daemon-reload，systemctl show 里新值已经生效，但业务行为没变，/proc 里的 limits 还是旧值。
一开始怀疑是「drop-in 目录里的配置优先级更高，覆盖了主文件」，查了一圈，方向不对。
原因不止一个，得分开看。daemon-reload 只重读 unit，不会重启已经在跑的进程。也可能是用 restart 但服务是 Type=notify，旧进程没完全退出。
不容易想到的是，进程被别的脚本直接拉起，不受当前 unit 管理。
动手时先确认运行中进程的实际限制
pid=$(systemctl show -p MainPID --value api); cat /proc/$pid/limits | head再往下检查有没有更高优先级的 drop-in
systemctl cat api | grep -n 'Drop-In'真正重启服务而不是只 reload
systemctl restart api等前面都确认过，再核对新进程的启动时间
systemctl show api -p ExecMainStartTimestamp -p MainPID改之前先确认了最近有没有人动过配置，避免白查一遍。
恢复的判定其实很直接。新 PID 的启动时间是刚才，/proc 里的 limits 显示新的限制值，业务日志级别也跟着变了。
daemon-reload 只是让 systemd 重新读配置，任何 unit 改动都要再 restart 才作用到进程。改动前把原配置备份一份，出问题能马上回滚，这比任何技巧都实用。