monit 默认轮询周期过长导致服务重启缓慢、状态显示为“does not exist”，根本原因在于其守护模式下依赖固定间隔轮询而非实时事件通知，需通过 `set daemon` 调整检查频率，并确保 pid 文件管理可靠。
Monit 是一个轻量级进程监控工具，但它并非基于内核事件（如 inotify 或 cgroup）的实时监控系统，而是采用周期性轮询（polling）机制来检测进程状态。这意味着：即使你配置了 start program ... with timeout 5 seconds，该 timeout 仅控制启动命令本身的执行等待时长（即 monit 启动脚本后最多等 5 秒确认进程是否已写入 PID 文件），并不影响 monit 多久检查一次进程是否存活。
真正决定“发现崩溃 → 触发重启 → 更新状态”整体延迟的关键参数，是全局守护模式轮询周期（daemon cycle），由 set daemon N 指令配置，默认值在多数发行版中为 120 秒（2 分钟）。从你的日志可见：
[Mar 5 08:04:44] info : 'site' trying to restart [Mar 5 08:06:44] info : 'site' process is running with pid 31479
——重启动作虽在 08:04:44 触发，但直到 2 分钟后（08:06:44）monit 才完成下一轮检查并确认新进程已运行，因此状态长期卡在 Does not exist。
✅ 解决方案：缩短轮询周期
编辑主配置文件 /etc/monit/monitrc（或 /etc/monit.conf），添加或修改以下行：
set daemon 5 # 单位：秒；建议设为 5~10 秒以平衡响应性与系统开销
⚠️ 注意：set daemon 必须位于配置文件顶部区域（在任何 check process 块之前），且只能出现一次。
同时，为提升可靠性，建议优化你的监控配置：
-
使用 start program + pidfile 组合时，确保 PID 文件写入原子且及时
当前 nohup ./goSite > /dev/null 2>&1 & echo $! > run.pid 存在竞态风险：Shell 启动后台进程后立即写入 $!，但此时 Go 程序可能尚未完成初始化或写入自身 PID（尤其当程序有初始化逻辑时）。推荐改用更健壮的方式：check process site with pidfile /root/go/path/to/goSitePath/run.pid start program = "/bin/bash -c 'cd /root/go/path/to/goSitePath && ./goSite < /dev/null > /dev/null 2>&1 & echo $! > run.pid'" stop program = "/bin/sh -c 'kill $(cat /root/go/path/to/goSitePath/run.pid 2>/dev/null) 2>/dev/null; rm -f /root/go/path/to/goSitePath/run.pid'" if does not exist then restart if failed host 127.0.0.1 port 3000 protocol http then restart # 可选：增加健康检查 depends on site_bin -
添加依赖声明（可选但推荐）
显式声明二进制文件依赖，避免因文件缺失导致误判：check file site_bin with path /root/go/path/to/goSitePath/goSite if failed checksum then unmonitor if failed permission 755 then unmonitor if failed uid root then unmonitor if failed gid root then unmonitor -
重启 monit 生效配置
sudo monit reload # 或 systemctl restart monit
? 额外建议：评估 supervisord 替代方案
若对启动感知速度要求极高（毫秒级响应），或需更细粒度的生命周期管理（如自动重定向 stdout/stderr、进程组管理），可考虑迁移至 supervisord —— 它通过 fork() 直接管理子进程，能即时捕获 SIGCHLD 事件，无需轮询，状态更新更准确及时。
总结：Monit 的“慢重启”和“Does not exist”状态本质是设计使然，非配置错误。核心修复动作只有两个：① 设置 set daemon 5 缩短轮询间隔；② 确保 start program 中 PID 写入与进程启动严格同步。 完成后，崩溃检测与恢复通常可在 5–15 秒内完成，状态显示也将实时更新为 Running。
