Linux监控进程需用户态方案，因内核watchdog不感知进程；可用脚本轮询（pgrep）、swatchdog（日志触发）、userspace watchdog程序或C语言父子进程管理，核心是确保监控自身比被监控进程更稳定。
Linux 里用 watchdog 监控进程状态，不能直接靠内核级 /dev/watchdog 设备——它只管系统级“喂狗”，不感知具体进程存不存在。真要监控某个服务进程（比如 nginx、redis-server），得用用户态方案：要么写脚本轮询，要么用专用工具如 swatchdog 或第三方 watchdog 程序，或者在应用里自己集成子进程管理逻辑。
用 shell 脚本轮询检查进程是否存活
这是最轻量、最可控的方式，适合嵌入式或无额外依赖的环境。核心就是定期 ps + grep 判断进程是否存在，再决定是否拉起。
-
ps的参数要小心：不同发行版（如 Alpine vs Ubuntu）ps默认行为不同，推荐用ps -eo pid,comm,args避免字段错位 - 匹配时别漏掉
grep -v grep，否则每次检查都会误判自己为“进程存在” - 避免重复启动：用
pgrep -f "your_cmd"比ps | grep更可靠，且能直接拿到 PID - 示例片段：
while true; do if ! pgrep -f "redis-server" > /dev/null; then systemctl start redis-server 2>/dev/null || /usr/bin/redis-server /etc/redis.conf & fi sleep 10 done
用 swatchdog 监控日志触发重启
swatchdog 不是监控进程本身，而是监控日志中与进程崩溃相关的线索（比如 Segmentation fault、exited with code 1），适合已有日志输出的守护进程。
Linux Ai Server
下载
Linux AI 服务器 — 将 Linux 服务器转换为本地 AI 推理集群。使用 systemd、NVIDIA CUDA 实现无头 Linux AI，零 GUI 开销。
- 安装后必须指定配置文件路径，否则默认读
$HOME/.swatchdogrc，容易权限或路径错误 - 正则要加锚点：写
watchfor /exited with code [1-9]/比/exited/更精准，避免误匹配正常日志 - 动作支持
exec，但注意 shell 环境隔离：用exec "/bin/sh -c 'systemctl restart myapp'"，否则可能找不到systemctl - 日志文件路径必须可读，且
swatchdog进程需有对应权限；若用journalctl，得配合systemd-journal-gatewayd或转存为文件
用 userspace watchdog 程序做进程级看门狗
社区有个叫 watchdog 的用户空间程序（非内核模块），它支持配置项直接监控进程、文件、网络端口等，比手写脚本更健壮。
- 配置文件里用
pidfile或procname指定目标，例如：procname = nginx pidfile = /var/run/nginx.pid
- 它会检查进程是否响应信号（
kill -0 $PID），比单纯查 PID 文件更准 - 注意
watchdog自身不能挂：它默认以 daemon 运行，但若配置错误导致崩溃，整个监控就失效了；建议配合systemd的Restart=always管理它自己 - 超时时间（
interval）设太短（如 2s）可能误杀正常高负载进程；建议从 30s 起调，观察实际恢复时间再收紧
在 C 程序里用 fork + waitpid 实现父子进程看门狗
如果你控制源码，最可靠的方式是在主程序里 fork() 出子进程跑业务，父进程用 waitpid() 阻塞等待——子进程一崩，父进程立刻收到 SIGCHLD 并重启。
- 别忽略
sigaction()设置SA_NOCLDWAIT，否则僵尸进程堆积 - 子进程退出码要判断：不是所有非零退出都代表崩溃，比如
exit(2)可能是配置错误，不该无脑重启 - 重试要有退避：连续失败 3 次后 sleep 加倍，避免快速循环重启把磁盘或日志打爆
-
execve()前记得close()不需要的 fd，尤其别让子进程继承父进程打开的/dev/watchdog设备
真正麻烦的不是“怎么写”，而是“怎么定义‘进程异常’”——是没进程？还是进程活着但端口不响应？或是日志里出现特定错误串？不同场景得选不同监控粒度，而且所有方案都绕不开一个点：监控进程自己必须比被监控进程更稳，否则就成了单点故障。
