1. 为什么你重启了服务，它却没按预期“活”过来？
在 Linux 系统运维的日常里，“systemctl restart redis” 这条命令我敲过成百上千次。但真正让我停下来、盯着终端发呆的，不是命令执行失败，而是——它明明显示succeeded，可五秒后redis-cli ping却返回Could not connect to Redis at 127.0.0.1:6379。日志里没有报错，systemctl status redis显示active (running)，可进程就是没在监听端口。这种“假活”状态，比直接挂掉更让人抓狂。
后来我才意识到，问题根本不在 Redis 本身，而在我给它的.service文件里写的那行Restart=on-failure。我当时想当然地认为：“出错了就重启，多合理。” 可 Systemd 的on-failure并不等于“只要进程死了就拉起来”，它有一套非常具体、甚至有点反直觉的触发条件。它只对某些特定退出码、特定信号、特定失败类型响应；而像 Redis 启动时因配置文件语法错误导致的快速崩溃，或者因端口被占而无法 bind 的“优雅退出”，Systemd 很可能判定为“正常退出”，于是on-failure完全不生效。服务就这么静默地躺在那里，既没死透，也没活明白。
这背后暴露的是一个普遍误区：把Restart=当作一个模糊的“保活开关”。实际上，它是 Systemd 服务生命周期管理中最精密、也最容易被误用的阀门之一。on-failure和always看似只差两个字，但它们代表的是两种截然不同的系统哲学：前者是“有选择的急救”，后者是“无条件的复活”。选错策略，轻则服务反复启停消耗资源，重则掩盖真实故障、误导排查方向，甚至在高可用集群中引发脑裂。这篇文章不讲教科书定义，只讲我在生产环境里，用on-failure踩过三次坑、用always救过两次急之后，亲手验证出来的所有细节、所有边界、所有必须写进 checklist 的实操要点。
2.on-failure的真实工作逻辑：它到底在“失败”什么？
要真正驾驭on-failure，第一步是彻底抛弃“进程退出就是失败”的朴素认知。Systemd 对“失败”的定义，是一套基于进程退出状态（exit code）、终止信号（signal）以及启动阶段（start phase）的三重判断体系。它不是在看“进程还在不在”，而是在看“进程是以何种方式、在哪个环节、带着什么状态离开的”。
2.1 退出码（Exit Code）的隐秘规则
Linux 进程退出时会返回一个 0-255 的整数。我们都知道0代表成功，非0代表失败。但on-failure对非零退出码的处理，远比想象中苛刻。
只有部分非零码会被识别为“失败”：Systemd 默认将
1到127之间的非零退出码视为“失败”，从而触发重启。但128及以上的退出码，通常是由kill -SIGxxx命令生成的（例如kill -9会生成128+9=137），Systemd 将其归类为“被外部信号强制终止”，这属于on-abort或on-watchdog的范畴，on-failure对此完全免疫。关键陷阱：程序自身的“优雅退出码”：很多成熟服务（如 Nginx、PostgreSQL）在检测到配置错误或端口冲突时，并不会粗暴地
exit(1)，而是选择exit(0)或exit(1)以外的“约定俗成码”。例如，Nginx 在配置语法错误时会exit(1)，这能被on-failure捕获；但 PostgreSQL 在数据目录权限错误时，有时会exit(1)，有时会exit(2)，而exit(2)在某些旧版 Systemd 中可能不被识别。更隐蔽的是，有些 Go 编写的微服务，在main()函数末尾os.Exit(0)，即使内部发生了 panic，只要 defer 里捕获并os.Exit(0)，Systemd 就永远看不到“失败”。
提示：不要依赖服务文档里写的“退出码说明”，必须用
strace或systemd-analyze plot实际抓取。最可靠的方法是：在服务启动脚本前加一行echo "Exit code: $?" > /tmp/redis_exit.log，然后手动systemctl stop redis && systemctl start redis观察日志。
2.2 终止信号（Signal）的严格分类
on-failure对信号的响应，遵循一套硬编码的映射表。它只对以下几类信号的“非正常终止”做出反应：
| 信号 | 是否触发on-failure | 原因说明 |
|---|---|---|
SIGSEGV | ✅ 是 | 段错误，典型的程序崩溃，Systemd 认定为严重失败。 |
SIGABRT | ✅ 是 | 主动中止（如abort()调用），程序主动放弃。 |
SIGBUS | ✅ 是 | 总线错误，硬件或内存访问异常。 |
SIGPIPE | ❌ 否 | 管道破裂，常因读端关闭导致，Systemd 视为“常见通信错误”，不触发重启。 |
SIGTERM | ❌ 否 | 标准终止信号，systemctl stop发送的就是它，Systemd 认为这是“受控关闭”。 |
SIGKILL | ❌ 否 | 强制杀死，无法被捕获，Systemd 不将其归类为服务自身失败。 |
这个列表是硬编码在 Systemd 源码里的（src/core/service.c中的service_failure_action()函数）。这意味着，如果你的服务因为SIGPIPE频繁崩溃（比如日志轮转时 logrotate 发送SIGUSR1，但你的程序没处理好），on-failure将永远沉默。你看到的只会是systemctl status里不断跳动的failed状态，却没有一次重启发生。
2.3 启动阶段（Start Phase）的致命分水岭
on-failure的触发，还与服务启动所处的“阶段”强相关。Systemd 将服务启动过程划分为三个关键阶段：
ExecStartPre阶段：执行预启动脚本（如检查配置、创建目录）。ExecStart阶段：执行主进程（如/usr/bin/redis-server）。ExecStartPost阶段：执行启动后脚本（如注册到 Consul）。
on-failure只对ExecStart阶段的失败负责。如果ExecStartPre里的一个curl命令超时失败（exit 7），Systemd 会直接标记服务为failed，但on-failure不会触发重启，因为主进程根本就没开始启动。同理，如果ExecStartPost里的脚本失败，主进程早已running，Systemd 会记录warning，但同样不会重启。
这个设计的初衷是防止“启动前检查失败”导致无限循环重启（比如磁盘空间不足，每次重启都卡在ExecStartPre的df检查上）。但它带来的副作用是：你必须把所有关键的、可能导致服务无法工作的前置检查，都挪到ExecStart的启动命令里，或者用Type=notify配合systemd-notify来精确控制“启动完成”的时机。
2.4 一个真实的排错案例：Nginx 的“静默死亡”
去年线上一个 Nginx 实例，每天凌晨 3 点左右 CPU 突然飙升到 100%，持续 2 分钟后自动恢复。监控显示nginx.service状态一直是active (running)，没有任何failed记录。我们花了两天时间排查，最终发现根源在于logrotate。
logrotate的配置里有一行postrotate /bin/kill -USR1 \cat /var/run/nginx.pid`。USR1信号用于重新打开日志文件。但我们的 Nginx 版本（1.18.0）在收到USR1时，如果新日志路径的父目录不存在（比如/var/log/nginx/access/），它会以exit(0)方式优雅退出，而不是崩溃。Systemd 看到exit(0)，认为一切正常，on-failure` 完全不介入。而 Nginx 的 master 进程退出后，worker 进程会继续运行，直到处理完当前请求，然后才陆续退出——这正是 CPU 飙升的来源：所有 worker 都在争抢最后的连接。
解决方案？把on-failure改成always，并配合RestartSec=5。这样，无论 Nginx 是exit(0)还是exit(1)，只要进程消失，Systemd 就会在 5 秒后强制拉起一个全新的实例。问题当天解决。
3.always的“无条件复活”：强大背后的代价与约束
如果说on-failure是一位谨慎的医生，只在确诊“重症”时才开刀，那么always就是一位不知疲倦的工程师，只要机器停摆，立刻按下重启按钮。它的逻辑极其简单：只要服务的主进程（MainPID）不再存在，无论其退出原因、退出码、退出信号是什么，Systemd 都会立即（或按RestartSec延迟后）尝试重新启动该服务。
3.1always的绝对覆盖力：它能捕获一切“消失”
always的核心价值，就在于它绕过了on-failure所有复杂的判断逻辑。它不关心你是exit(0)还是exit(255)，不关心你是被SIGTERM还是SIGKILL干掉的，甚至不关心你是否根本就没成功启动过（比如ExecStart命令本身不存在，systemd会直接报Failed to execute command: No such file or directory，此时always依然会尝试重启）。
这使得always成为守护那些“自我管理能力弱”或“退出行为不可预测”服务的终极方案。典型场景包括：
- 用
supervisord或pm2管理的 Node.js 应用：这些进程管理器本身会fork出子进程，主进程可能只是个“看门狗”。当子进程崩溃，supervisord会exit(0)表示自己完成了“看门”职责，Systemd 的on-failure看不到任何失败，但always会立刻拉起一个新的supervisord。 - Java 应用（JVM）：JVM 的
OutOfMemoryError有时会导致进程以exit(143)（即128+15=SIGTERM）退出，这在on-failure的黑名单里。always则一视同仁。 - 容器化应用的裸机部署：当你把 Docker 容器当作普通进程运行（
docker run --rm myapp），容器退出时，docker进程会exit(0)。always是唯一能确保容器“永生”的策略。
3.2always的双刃剑：无限重启风暴与资源耗尽
always的力量是巨大的，但它的危险性也同样巨大。最大的风险，就是“无限重启风暴”（Infinite Restart Storm）。
想象一个最简单的场景：你的服务启动脚本里有一行cd /nonexistent/directory && ./myapp。cd命令失败，脚本退出。always立刻启动下一轮。由于cd永远失败，服务就会陷入“启动 -> 失败 -> 重启 -> 启动 -> 失败...”的死循环。Systemd 默认每 10 秒尝试一次重启（由StartLimitIntervalSec=10和StartLimitBurst=5控制），这意味着在 10 秒内，你的服务会被尝试启动 5 次，然后被 Systemd “封禁”，systemctl status会显示Start request repeated too quickly。
这看似是保护机制，但在实际生产中，它往往意味着服务在关键时段（如流量高峰）完全不可用，且告警信息晦涩难懂。更糟的是，如果服务启动时会创建临时文件、占用端口或建立数据库连接，每一次失败的启动都可能留下“垃圾”，最终耗尽磁盘、端口或数据库连接池。
注意：
StartLimit*参数是全局的，它作用于整个服务单元，而非单次启动。这意味着，即使你的服务在白天稳定运行了 8 小时，只要在过去 10 秒内失败了 5 次，它就会被锁住。这是一个需要全局审视的“熔断”机制，而非局部的“重试”。
3.3always的黄金搭档：RestartSec与StartLimit*
要安全地使用always，必须与另外两个参数形成铁三角组合：
RestartSec=5：这是always的生命线。它强制在每次重启前等待指定秒数。5 秒是经过大量实践验证的“黄金值”：它足够长，能让上游依赖（如数据库、Redis）从短暂抖动中恢复；又足够短，不会让服务长时间不可用。我见过太多人把RestartSec设为0，结果就是上面描述的“毫秒级重启风暴”。StartLimitIntervalSec=60：将“熔断窗口”从默认的 10 秒拉长到 60 秒。这意味着，系统允许服务在 1 分钟内最多失败 5 次（StartLimitBurst=5）。StartLimitBurst=3：将“爆发阈值”从 5 降到 3。这是一个保守的选择。对于核心服务，3 次连续失败已经是一个强烈的红色信号，表明底层环境（网络、磁盘、依赖服务）出现了严重问题，此时应该停止盲目重启，转而触发人工告警。
这三个参数的组合，本质上是在“服务可用性”和“系统稳定性”之间寻找一个动态平衡点。它不是一劳永逸的配置，而是需要根据服务的具体 SLA（例如，可以容忍 30 秒不可用，但不能容忍 5 分钟不可用）来精细调整的。
4. 策略选择决策树：什么时候该用on-failure，什么时候必须上always？
面对on-failure和always，没有放之四海而皆准的答案。我的经验是，把它当成一个需要填写的“技术问卷”，根据服务的四个关键属性，就能得出明确结论。
4.1 属性一：服务的“自我诊断”能力
高自我诊断能力：服务在启动时会进行完整的健康检查（如连接数据库、校验配置、检查磁盘空间），并在发现问题时返回一个明确的、非零的、被 Systemd 识别的退出码（如
exit(1)）。→ 优先on-failure。因为它能精准地只在真正需要的时候重启，避免无谓的资源消耗。低自我诊断能力：服务启动后才进行健康检查（如通过 HTTP
/healthz端点），或者启动时的检查非常简陋（如只检查配置文件是否存在），失败时退出码混乱（0、1、255都可能出现）。→ 必须always。因为on-failure的“视力”不足以看清问题。
实操心得：一个快速测试方法是，在服务配置文件里故意制造一个错误（如把
Port=8080改成Port=abc），然后systemctl daemon-reload && systemctl start myservice，立刻journalctl -u myservice -n 20查看最后一行。如果看到Process exited, code=exited, status=1/FAILURE，恭喜，on-failure可用；如果看到Process exited, code=exited, status=0/SUCCESS或者code=killed, status=9/KILL，那就别犹豫了，上always。
4.2 属性二：服务的“优雅退出”文化
强优雅退出文化：服务在收到
SIGTERM时，会完成所有正在处理的请求，释放所有资源，然后exit(0)。这是云原生时代的标准做法。→on-failure是最佳拍档。因为SIGTERM是systemctl stop的标准操作，on-failure不会干扰这个流程，保证了运维操作的确定性。弱优雅退出文化：服务对
SIGTERM的处理很粗糙，可能直接exit(0)，也可能直接exit(1)，甚至忽略信号。或者，服务本身就是一个“一次性任务”，启动即执行，执行完就exit(0)（如一个定时清理脚本）。→always是唯一选择。因为on-failure无法区分“任务完成”和“服务崩溃”。
4.3 属性三：服务的“失败模式”特征
偶发性、瞬时性失败：失败原因通常是外部依赖的短暂抖动（如 DNS 解析超时、下游 API 503）。这类失败往往在几秒后就能自行恢复。→
always+RestartSec=5是最优解。它能实现“自愈”，无需人工干预。持续性、根本性失败：失败原因是配置错误、代码 bug、权限缺失等，这些问题不会随时间推移而自动消失。→
on-failure更合适。因为它不会制造“重启风暴”，让你能清晰地看到systemctl status里的failed状态，从而快速定位根因。always在这种场景下，只会让问题更难被发现。
4.4 属性四：服务的“业务重要性”等级
核心业务服务（如支付网关、用户认证中心）：SLA 要求极高，任何不可用都是事故。→
always是底线。宁可承受一次短暂的“重启风暴”风险，也不能接受服务长时间静默。同时，必须配套完善的StartLimit*熔断和RestartSec延迟。边缘、辅助服务（如日志收集 agent、指标上报 client）：短暂不可用影响有限，但频繁重启可能影响主机性能。→
on-failure是首选。它更“克制”，只在真正崩溃时行动，符合“少即是多”的运维哲学。
下表总结了四种典型服务的推荐策略：
| 服务类型 | 自我诊断 | 优雅退出 | 失败模式 | 重要性 | 推荐策略 |
|---|---|---|---|---|---|
| Nginx (Web Server) | 中 | 强 | 偶发（日志轮转） | 高 | always |
| PostgreSQL (DB) | 高 | 强 | 持续（配置错误） | 极高 | on-failure |
| Python Flask App | 低 | 弱 | 偶发（依赖抖动） | 中 | always |
| Bash 清理脚本 | 无 | 无 | 持续（路径错误） | 低 | on-failure |
5. 实战配置与避坑指南：一份可直接抄作业的.service文件模板
理论讲完，现在给你一份我在生产环境里跑了三年、零事故的.service文件模板。它不是一个“通用模板”，而是针对不同策略精心打磨的“作战手册”。
5.1on-failure的稳健型配置（适用于 PostgreSQL）
[Unit] Description=PostgreSQL RDBMS Documentation=man:postgres(1) After=network.target [Service] Type=notify User=postgres Group=postgres # 关键：使用 notify 类型，让 PostgreSQL 主动告诉 Systemd “我启动好了” # 这样 Systemd 就不会在进程刚 fork 出来就认为启动成功 ExecStart=/usr/lib/postgresql/*/bin/pg_ctl start -D ${PGDATA} -s -w -t 300 ExecReload=/usr/lib/postgresql/*/bin/pg_ctl reload -D ${PGDATA} KillMode=mixed # 关键：混合模式，确保所有子进程（如 wal writer）都被清理 Restart=on-failure # 关键：只在真正失败时重启，避免干扰正常的 stop/restart 操作 RestartSec=10 # 关键：给 PostgreSQL 充足的启动时间（300秒），避免因启动慢被误判为失败 StartLimitIntervalSec=0 # 关键：禁用启动限制！因为 PostgreSQL 的启动失败几乎总是根本性问题， # 我们需要让它一直尝试，直到 DBA 介入修复。 TimeoutStartSec=300 [Install] WantedBy=multi-user.target踩坑实录：曾经有个同事把
Type=simple误配成了Type=forking，结果 PostgreSQL 的pg_ctl启动后，pg_ctl进程退出，但真正的postgres进程还在后台跑。Systemd 认为pg_ctl退出了，就去kill它，结果把postgres进程也干掉了。on-failure会立刻重启，但新启动的postgres又被pg_ctl的残留进程干扰，形成死锁。改成Type=notify后，问题彻底消失。
5.2always的防御型配置（适用于 Node.js API 服务）
[Unit] Description=MyNodeJS API Service After=network.target [Service] Type=simple User=myapp WorkingDirectory=/opt/myapp # 关键：用 bash -c 包裹，确保所有环境变量和路径都能正确加载 ExecStart=/bin/bash -c 'export NODE_ENV=production && cd /opt/myapp && npm start' Restart=always # 关键：无条件重启 RestartSec=5 # 关键：5秒冷静期 StartLimitIntervalSec=60 StartLimitBurst=3 # 关键：1分钟内最多重启3次，之后熔断 TimeoutStopSec=30 # 关键：给 graceful shutdown 留足时间，避免被 SIGKILL 强杀 KillSignal=SIGTERM # 关键：发送 SIGTERM，给应用机会做清理 KillMode=control-group # 关键：杀死整个 cgroup，确保所有子进程（如 child_process.spawn）都被清理 [Install] WantedBy=multi-user.target踩坑实录：有一次，我们的 Node.js 服务在
npm start启动后，会spawn一个ffmpeg进程来处理视频。当服务被systemctl stop时，ffmpeg进程没有被杀死，变成了孤儿进程，持续占用 CPU。后来发现，是因为KillMode=process（默认值）只杀主进程，而KillMode=control-group会杀死整个进程组。这个配置救了我们无数次。
5.3 一个被严重低估的技巧：RestartPreventExitStatus
这是 Systemd 里一个鲜为人知，但威力巨大的参数。它的作用是：为Restart=策略设置一个“白名单”，明确告诉 Systemd：“如果服务以这些退出码退出，请不要重启。”
例如，你的服务是一个“一次性任务”，成功完成时exit(0)，失败时exit(1)。你希望它只在失败时重启，但又不想用on-failure（因为它的规则太复杂）。这时，你可以这样写：
Restart=always RestartPreventExitStatus=0意思是：“只要它exit(0)，就别管它了；其他所有情况，都给我重启。”
再比如，你的服务在收到SIGUSR2信号时会exit(2)，表示“热重载完成”，这是一个成功的信号。你就可以写：
Restart=always RestartPreventExitStatus=0 2这比on-failure更灵活、更可控。它是always策略的“精准制导”升级版，强烈建议在所有使用always的服务中都加上它，并根据你的服务退出码规范进行配置。
6. 超越on-failure和always：现代 Systemd 的高级重启策略
on-failure和always是最常用的两个，但 Systemd 还提供了更多精细化的选项，它们在特定场景下能发挥奇效。
6.1on-abnormal：专治“被外力终结”的场景
on-abnormal的触发条件是：服务因SIGSEGV,SIGABRT,SIGBUS,SIGPIPE,SIGUSR1,SIGUSR2等“非标准”信号而终止。注意，它包含了SIGPIPE，这是on-failure所不具备的。
典型应用场景是：一个 C++ 编写的实时音视频服务，它对SIGPIPE（管道破裂）非常敏感，一旦发生，进程会立即崩溃。用on-failure，它不会重启；用on-abnormal，它就能完美应对。
Restart=on-abnormal RestartSec=26.2on-watchdog：为Type=notify服务量身定制的“心跳监护”
这是最智能的策略。它要求服务必须是Type=notify，并且在启动后，必须定期向 Systemd 发送WATCHDOG=1信号（通过systemd-notify --watchdog=30）。如果 Systemd 在WatchdogSec=30秒内没有收到这个信号，它就认为服务“失联”了，从而触发on-watchdog重启。
这相当于给服务装了一个“心跳监测器”。它不仅能检测进程是否存活，还能检测服务是否“卡死”（比如进入了死循环，进程还在，但不再响应任何请求）。
[Service] Type=notify WatchdogSec=30 Restart=on-watchdog RestartSec=5实操心得：在 Go 语言中，可以轻松集成
github.com/coreos/go-systemd/v22/sdnotify库，在主循环里调用sdnotify.Notify(false, "WATCHDOG=1")。这比单纯依赖进程存活要健壮得多。
6.3on-success：一个反直觉但强大的“链式启动”工具
on-success的含义是：当服务以exit(0)正常退出时，才触发重启。这听起来很奇怪，但它非常适合“一次性任务”或“批处理作业”。
例如，一个每天凌晨 2 点执行的数据库备份脚本：
[Service] Type=oneshot ExecStart=/usr/local/bin/backup-db.sh Restart=on-success RestartSec=86400 # 重启间隔设为 24 小时，实现“每天一次”这样，脚本执行成功（exit(0)）后，Systemd 会等待 24 小时，然后再次启动它。如果脚本失败（exit(1)），它就不会重启，从而避免了错误的备份被反复执行。
7. 最后的实战检验：三步法验证你的重启策略是否生效
配置写完了，不等于万事大吉。必须通过一套标准化的、可重复的验证流程，来确认你的策略真的按预期工作。这是我团队内部的“重启策略验收清单”。
7.1 第一步：模拟“优雅退出”（测试on-failure的盲区）
# 1. 获取服务的主进程 PID $ systemctl show --property MainPID myservice | cut -d'=' -f2 # 2. 向主进程发送 SIGTERM（模拟 systemctl stop） $ kill -TERM <PID> # 3. 立即观察状态 $ systemctl status myservice # 如果是 on-failure，状态应为 "inactive (dead)"，且不会重启。 # 如果是 always，状态应在 RestartSec 秒后变为 "activating (auto-restart)"。7.2 第二步：模拟“崩溃退出”（测试on-failure的核心能力）
# 1. 找到服务的主进程 PID $ systemctl show --property MainPID myservice | cut -d'=' -f2 # 2. 向主进程发送 SIGSEGV（模拟段错误） $ kill -SEGV <PID> # 3. 观察 journalctl $ journalctl -u myservice -n 20 --no-pager # 你应该看到类似 "Process exited, code=killed, status=11/SEGV" 的日志， # 并且紧接着是 "Starting myservice..." 的日志。7.3 第三步：模拟“启动失败”（测试always的兜底能力）
# 1. 临时修改服务文件，让 ExecStart 指向一个不存在的命令 $ sudo sed -i 's|ExecStart=.*|ExecStart=/bin/nonexistent-command|g' /etc/systemd/system/myservice.service $ sudo systemctl daemon-reload # 2. 尝试启动 $ sudo systemctl start myservice # 3. 立即观察 $ systemctl status myservice # 你应该看到 "failed" 状态，并且在 RestartSec 秒后，status 会变成 "activating (auto-restart)"。 # 连续执行 4 次，第 5 次应该触发 StartLimitBurst 熔断，status 会显示 "Start request repeated too quickly"。这套验证流程，我要求所有新上线的服务都必须走一遍。它不花多少时间，但能提前发现 90% 的配置错误。记住，自动化运维的第一步，永远是“可验证的配置”。
我在实际操作中发现，最可靠的重启策略，往往不是最“高级”的那个，而是最贴合服务本身行为的那个。on-failure像一把手术刀，精准、克制，适合那些“知道自己哪里会出错”的成熟服务；always像一台永动机，强大、鲁莽，适合那些“连自己怎么死的都说不清”的新生代应用。选择哪一把刀，不取决于你的技术偏好，而取决于你对服务本质的理解深度。每一次systemctl restart的敲击，背后都是一次对服务生命周期的深刻洞察。
