不能，restart=always仅按主进程存续重启，不感知死锁、资源耗尽或子进程残留；需结合type=notify、外部探针或watchdog脚本实现真存活检测。
systemd 服务设为 Restart=always 就真能自动拉起吗
不能，靠 Restart=always 并不等于“服务挂了就一定能回来”。它只控制 systemd 自身的重启逻辑，不感知进程内部状态、资源耗尽或死锁。
- 如果进程 fork 出子进程后主进程退出，而子进程还在跑（常见于没做 daemonize 清理），systemd 会认为服务已终止，触发重启——但新实例可能和残留子进程冲突
-
RestartSec=5是重启前等待秒数，不是健康检查间隔；systemd 不主动探测进程是否“活着”，只看主 PID 是否还存在 - 若进程因 OOM 被杀，
Restart=always会生效，但若系统内存持续不足，新进程大概率立刻再被杀，形成“启动-崩溃-重启”循环，日志里堆满Process exited with code killed by signal KILL
怎么判断服务是不是真“活”着，而不是假启动
systemd 本身不提供端口/HTTP 健康检查，得靠 ExecStartPost 或外部探针配合 Type=notify 或 Type=forking 类型来补足。
- 用
Type=notify时，进程必须调用sd_notify(0, "READY=1")显式通知就绪；否则 systemd 一直卡在 activating 状态，后续 restart 逻辑也不触发 - 想检查端口，可以在
ExecStartPost=里加bash -c 'until nc -z 127.0.0.1 8080; do sleep 1; done'，但注意这会阻塞服务启动流程，超时需配TimeoutStartSec= - 更稳妥的做法是写个独立的 watchdog 脚本，用 cron 每 30 秒 curl
/health，失败则执行systemctl restart myapp.service，避开 systemd 的模型局限
哪些场景下自动拉起会彻底失效
systemd 的重启机制在以下情况直接不工作：
- 服务配置里写了
Restart=no（默认值），哪怕进程崩溃也不会重启 - 设置了
StartLimitIntervalSec=和StartLimitBurst=，比如 10 秒内连续失败 3 次，之后会进start-limit-hit状态，systemctl start都拒绝，得手动systemctl reset-failed - 依赖的 target（如
network.target）没就绪，而服务又没声明Wants=/After=，systemd 可能根本不尝试启动 - 服务跑在容器里且用了
--restart=always，此时宿主机 systemd 对容器内进程完全不可见，它的Restart=设置毫无意义
真正可靠的拉起策略长什么样
别把所有希望押在 Restart=always 上。可靠 = 进程管理 + 外部观测 + 快速降级。
- 进程自身要支持优雅退出：收到
SIGTERM后完成当前请求再退出，避免重启时连接中断或数据损坏 - 关键服务加一层 supervisor，比如用
supervisord管理 Python 子进程，或用runsv（runit）替代 systemd 直接拉起，它们对子进程树的掌控更细 - 监控必须覆盖“启动成功但功能异常”的情况：比如 HTTP 服务返回 200 但响应体是空，这种得靠业务层健康接口 + Prometheus + Alertmanager 实现闭环
- 磁盘满、inode 耗尽、ulimit 不足这些底层问题，systemd 无法感知，得靠
systemd-analyze blame和journalctl -u myapp --since "2 hours ago"定期巡检
自动拉起只是最后一道防线，不是免死金牌。最常出问题的地方，永远是“以为它活了，其实卡在某处不动了”。
