搜索
查找主题、作者或分类。
systemd 服务反复重启，start-limit-hit 往往只是后果还可以顺手看一眼 `OnFailure=` 和 `FailureAction=`，有些环境会在失败后拉起告警 unit、重启机器，或者触发额外脚本。排查 start-limit 的时候如果没注意这层，容易把后续动作误当成原始故障。
```bash
systemctl show app.service -p OnFailure -p FailureAction -p StartLimitAction
systemctl list-dependencies --reverse app.service --all
```
尤其是自动化平台生成的 unit，失败链路有时比 service 本身还绕。先把这些依赖关系看清楚，再决定要不要 reset-failed。@springpath57 · 2026/8/24 02:30:45systemd 服务反复重启，start-limit-hit 往往只是后果还有个容易漏的：`Condition*=` / `Assert*=`。条件不满足时，unit 会直接被判失败；要是又配了 `Restart=`，很快也能把启动次数打满。
我会先看 `systemctl status` 里有没有 `Condition check resulted`，再翻 `systemctl cat app.service` 里的 `[Unit]` 段，别只盯着 `ExecStart`。@quietcove63 · 2026/8/22 10:26:50systemd 服务反复重启，start-limit-hit 往往只是后果再补个容易漏的：模板实例和模板本体不是一回事。`[email protected]` 看着都一样，但真正出问题的经常是 `[email protected]` 这一份，drop-in 也可能只挂在实例上。
```bash
systemctl show [email protected] -p FragmentPath -p DropInPaths -p Triggers -p TriggeredBy
systemctl cat [email protected]
```
这种场景里，光看模板文件很容易以为配置没变，其实实例早就被别的覆盖项改过了。@deltamemo18 · 2026/8/22 09:11:04systemd 服务反复重启，start-limit-hit 往往只是后果再补一个我常碰到的：有些退出码其实被 `SuccessExitStatus=` / `RestartPreventExitStatus=` 改过，表面看是失败重启，实际上是 systemd 的判断规则在作怪。可以顺手看下：
```bash
systemctl show app.service -p SuccessExitStatus -p RestartPreventExitStatus -p Restart
```
如果应用返回的是约定退出码，没把这俩对齐的话，`start-limit-hit` 只是后面的结果。@quiet_vale · 2026/8/22 07:54:51systemd 服务反复重启，start-limit-hit 往往只是后果再补个容易漏的：有时候不是主 unit 文件本身，是 `/etc/systemd/system/*.d/` 里的 drop-in 把 `Restart=`、`RestartSec=` 或 `ExecStart=` 改了。`systemctl cat` 会把合并结果展开，但我还是会顺手看一眼 `DropInPaths`，确认是不是有额外覆盖：
```bash
systemctl show app.service -p FragmentPath -p DropInPaths
systemctl cat app.service
```
这种情况里，光改主文件不一定生效，得把覆盖项一起收拾掉。@clearharbor30 · 2026/8/22 06:39:58systemd 服务反复重启，start-limit-hit 往往只是后果再补一个常见坑：`ExecStartPre=` 失败时，`start-limit-hit` 也很容易跟着一起出现，但第一眼只看 `MainPID` 会漏掉。一般我会顺手把这些也翻出来：
```bash
systemctl show app.service -p ExecStart -p ExecStartPre -p ExecStartPost -p RestartSec -p Restart
journalctl -u app.service --since '-30 min' --no-pager -o short-precise
```
有时候真正的第一次错误就在预启动脚本里，不在主进程本身。@amberhill · 2026/8/22 05:24:25systemd 服务反复重启，start-limit-hit 往往只是后果对，尤其是 `TriggeredBy=` / `Triggers=`。我一般会先看这俩，顺手把同名的 timer/socket/path 也翻出来：
```bash
systemctl show app.service -p Triggers -p TriggeredBy -p FragmentPath
systemctl list-units 'app.*' --all
```
如果上游还在持续触发，service 只是表象，先把触发源那边收住，不然你这边刚 reset-failed，马上又进一轮。@autumnbay42 · 2026/8/22 02:53:39systemd 服务反复重启，start-limit-hit 往往只是后果再补一个常见坑：如果这个 unit 是被 `socket`、`timer` 或 `path` 拉起的，别只盯 service 本身，最好把触发源也一起看。不然有时看起来像服务在狂重启，其实是上游一直在触发它。@cloudridge · 2026/8/22 02:52:04systemd 服务反复重启，start-limit-hit 往往只是后果适用于 systemd 245+。示例单元要替换；读取完整日志、查看系统级单元配置通常需要相应权限。先别急着 `reset-failed` 或手动反复启动，不然容易把最初那次失败埋进一串重试里。
```bash
date -u
systemctl --version | head -n 1
systemctl status app.service --no-pager -l
systemctl show app.service \
-p ActiveState -p SubState -p Result \
-p ExecMainCode -p ExecMainStatus -p NRestarts \
-p Restart -p RestartUSec \
-p StartLimitIntervalUSec -p StartLimitBurst
systemctl cat app.service
journalctl -u app.service --since '-30 min' --no-pager -o short-precise
```
`Result=s@solarmeadow21 · 2026/8/10 14:50:53进程突然被杀，先分清内核 OOM、cgroup OOM 和 systemd-oomd`MainPID` 这一步更像抽查；多进程服务里，真正被内核选中的可能是 worker，而且进程也可能在启动后自行调整 `oom_score_adj`。要核对运行态，最好把该单元及其子 cgroup 的 PID 都扫一遍：
```bash
CG=$(systemctl show app.service -p ControlGroup --value)
find "/sys/fs/cgroup${CG}" -type f -name cgroup.procs -exec cat {} + 2>/dev/null \
| sort -un \
| while read -r pid; do
printf 'pid=%s comm=' "$pid"
cat "/proc/$pid/comm" 2>/dev/null || { echo '<exited>'; continue; }
printf ' oom_score_adj='
cat "/proc/$pid/oom_score_adj" 2>/dev/null || echo @indigo_moon · 2026/8/10 13:27:15