kill -0 $PID 是最轻量检查进程是否存活且可响应的方法，返回0表示存在并可响应，1表示不存在或权限不足，2表示PID格式错误。
进程是否存在且可响应？用 kill -0 最轻量
检查一个进程是否存活，最直接的方式不是看它有没有在 ps 里，而是尝试向它发一个不带信号的探测——kill -0 $PID。这个操作不会终止进程，仅由内核验证 PID 是否存在、当前用户是否有权限向其发送信号。
常见错误是用 ps aux | grep myapp，这容易误判：grep 进程自身会匹配上，或进程名被截断、有空格导致漏检；更糟的是，进程可能卡死但仍在进程表中。
-
kill -0返回 0 表示进程存在且可响应（至少没被冻结或僵尸化） - 返回 1 表示进程不存在，或权限不足（如跨用户检查需 root）
- 返回 2 表示 PID 格式错误或为负数（比如传了字符串）
如何判断进程“活着但没干活”？加超时 + I/O 检查
仅靠 kill -0 不足以说明服务可用——进程可能卡在死锁、无限循环或阻塞 I/O 上。这时需要结合外部可观测性手段：
- 对监听端口的服务，用
timeout 3 bash -c 'echo > /dev/tcp/127.0.0.1/8080' 2>/dev/null测试 TCP 连通性（注意：需启用bash的/dev/tcp支持） - 对提供 HTTP 接口的服务，用
curl -f -s -o /dev/null --max-time 3 http://localhost:8080/health；-f确保非 2xx 响应也报错 - 检查关键文件句柄是否异常增长：
lsof -p $PID | wc -l，长期持续上涨可能是资源泄漏迹象
systemd 服务怎么写健康检查？用 ExecStartPre 和 HealthCheck
如果你用 systemd 管理进程，别自己写轮询脚本。v240+ 的 systemd 原生支持 HealthCheck，但前提是服务声明为 Type=notify 或 Type=exec 并配合 WatchdogSec=。
更通用稳妥的做法是利用 ExecStartPre + 自定义检查脚本，或在服务启动后由外部探针驱动：
- 在 unit 文件中加
Restart=on-failure和RestartSec=5，让 systemd 在进程退出非零码时自动拉起 - 用
systemctl is-active --quiet myapp.service && systemctl is-failed --quiet myapp.service组合判断“运行中且未失败” - 避免在
ExecStart中嵌套复杂健康逻辑——这会让 systemd 无法准确识别主进程，导致systemctl stop失效
为什么不能只依赖 ps 或 pidof？它们不反映真实状态
pidof myapp 或 pgrep myapp 只查进程名匹配，而现代应用常以相同名字启动多个实例（比如多 worker），或改名（prctl(PR_SET_NAME)），甚至 fork 后主进程退出、子进程继续跑——这时 pidof 找不到主 PID，但服务仍可用。
更隐蔽的问题是僵尸进程（Z 状态）：它还在进程表里，ps 能看到，但已不可交互，kill -0 会失败。这类进程必须由父进程 wait，否则只会越积越多。
真正可靠的健康检查永远要贴近业务语义：HTTP 服务看 /health 返回，数据库看能否执行 SELECT 1，消息队列看能否 publish/consume。进程层只是第一道门，别让它成为唯一依据。
