这个坑值得记一笔。Ubuntu 20.04 上一台 nginx 的 unit 里，ExecStartPre 是拉远程配置的脚本，某次发布后 systemctl status 一直停在 Activating (start)，十分钟后被 kill，日志里只有一行 Starting。
原因不止一个，得分开看。ExecStartPre 里的脚本用 curl 拉远端配置，网络不通时默认等到天荒地老；脚本里从 stdin 读输入，systemd 下没有终端，读操作一直阻塞；Type=notify 但程序不发 READY=1，systemd 只能等到超时才判定失败。
手工跑一遍前置脚本看卡点
bash -x /usr/local/bin/gen-conf.sh给前置步骤加硬超时
[Service] ExecStartPre=/usr/bin/timeout 30 /usr/local/bin/gen-conf.sh然后确认服务类型与实际行为匹配
systemctl show nginx -p Type等前面都确认过，再重载后再重启
systemctl daemon-reload && systemctl restart nginx手上没有现成的复现脚本，就照着线上请求手工拼了一个。
报错是间歇性的，我蹲守了半小时才抓到一次完整现场。
怎么算真的好了，看的是同一批现象。systemctl show nginx -p ActiveState 变为 active、SubState 为 running，systemd-analyze blame 里该 unit 的启动耗时低于 5 秒。
补一句。前置脚本别做网络请求，配置要预先落地；Type=notify 配错会让健康的服务被判超时，升级 systemd 后要重看这一项。监控比日志更早给出信号，事后回看经常能提前半小时发现异常。