Workerman 5.2.3 进程异常退出需分层监控（master/worker）、捕获关键信号、保留可追溯日志；优先检查master存活、worker数量、退出状态码、PHP禁用函数及监听地址，并用shell脚本实现自动巡检。
Workerman 5.2.3 进程异常退出，不能只等告警才反应——得提前布好“哨兵”。核心思路是：**分层监控（master / worker）、抓关键信号、留可追溯痕迹**。下面直接说实用做法。
看 master 进程是否还在
master 一挂，整个服务就断了。这是最优先检查项：
- 执行 ps aux | grep "start\.php"，确认输出里有
WorkerMan: master process；若只剩grep自身或完全无结果，说明 master 已退出 - 搭配 systemctl status workerman（如用 systemd 管理）或 supervisorctl status（如用 supervisor），看主进程状态是否为
RUNNING - 检查 workerman.log 最末几行，找类似
Master process exit或PHP Fatal error的记录
查 worker 子进程是否集体消失
master 活着但服务不可用？大概率是所有 worker 都崩了：
- 运行 ps aux | grep "WorkerMan: worker process"，正常应有多个（数量 =
Worker::$count）；若一个都没有，说明 worker 全退出了 - 日志中重点搜
exit with status后面的数字：
– 256 → PHP 被内核强制终止（禁用函数如pcntl_fork被拦、扩展崩溃）
– 139 → 段错误（SIGSEGV），多由 amqp/redis/opcache 等扩展引发
– 其他非 0 值 → 查对应 Linux 信号号（如 134=SIGABRT） - 临时加调试：在
start.php开头加ini_set('log_errors', 'On'); ini_set('error_log', '/tmp/workerman_php_error.log');，确保 PHP 致命错误不静默
用官方检测脚本和配置快速筛硬伤
很多退出根本不是代码问题，而是环境卡点：
- 立刻跑：curl -Ss http://www.workerman.net/check.php | php —— 它会直报
pcntl、posix、sockets是否启用，以及哪些关键函数被disable_functions拦住 - 手动确认：php -i | grep disable_functions，重点盯
pcntl_fork、posix_kill、posix_getpid是否在列表里 - 检查监听地址：用 ss -tuln | grep :你的端口，若只显示
127.0.0.1:xxx，说明绑定错了，外部连不上，worker 可能因连接失败反复重启
加一层轻量级自动巡检（推荐 shell 脚本）
不用上 Prometheus，一个定时脚本就能守住底线：
- 写个
check_workerman.sh： #!/bin/bash
if ! pgrep -f "start\.php" > /dev/null; then
echo "$(date) Workerman master missing" >> /var/log/workerman_alert.log
systemctl restart workerman # 或发微信/邮件告警
fi
if [ $(pgrep -f "WorkerMan: worker process" | wc -l) -lt 2 ]; then
echo "$(date) Too few workers" >> /var/log/workerman_alert.log
fi - 加入 crontab：*/2 * * * * /path/to/check_workerman.sh
