workerman频繁重启主因是业务代码fatal error、守护模式pidfile配置错误或监听地址不当；需通过错误日志捕获、pidfile权限验证及ss命令检查监听状态来精准定位。
Workerman服务频繁重启不是偶然现象，而是业务代码异常、配置错误或系统环境不兼容在运行时集中暴露的结果；每次Worker子进程因Fatal Error终止后，主进程会立即拉起新进程，形成“崩溃→重启→再崩溃”的循环，日志里反复出现exit code非零、worker_id跳变、时间戳密集堆积就是典型信号。
业务代码触发Fatal Error导致子进程秒退
第一步：在start.php最顶部插入错误捕获开关：ini_set('log_errors', 'On'); ini_set('error_log', '/var/log/workerman_fatal.log');
第二步：添加shutdown钩子，只记录Fatal类错误：register_shutdown_function(function() { $err = error_get_last(); if ($err && in_array($err['type'], [E_ERROR, E_PARSE, E_CORE_ERROR, E_COMPILE_ERROR, E_USER_ERROR])) { file_put_contents('/var/log/workerman_fatal.log', date('Y-m-d H:i:s') . " PID: " . getmypid() . " FATAL: " . $err['message'] . "\n", FILE_APPEND); } });
第三步：检查onMessage/onWorkerStart等回调里是否调用了未定义函数、require了不存在的文件、使用了被disable_functions拦截的关键函数（如pcntl_fork）——【pcntl_fork和posix_kill被禁用会导致master无法管理worker，必然闪退】
守护进程模式静默失败引发假性重启
方法一：确认启动命令是否带-d参数
php start.php start 【-d】 是唯一合法的后台启动方式，不加-d就是前台进程，终端关闭即退出。
方法二：验证pidFile路径是否绝对且可写
必须设为绝对路径，例如$worker->pidFile = '/var/run/workerman.pid';；若目录不存在或权限不足，-d会静默失败，进程启动几秒后自动退出，看起来像“刚启就挂”。
方法三：手动测试pidFile写入能力
sudo -u www-data touch /var/run/workerman.pid && sudo -u www-data rm /var/run/workerman.pid —— 若报Permission denied，说明运行用户无写权限，需执行chown www-data:www-data /var/run。
外部连接异常引发连接风暴式崩溃
监听地址写成127.0.0.1是高频陷阱
硬件设备或局域网客户端发包到服务器真实IP，而Workerman只监听127.0.0.1，内核直接丢弃请求；客户端不断重连→服务端建立大量半开连接→资源耗尽→Worker进程被系统OOM killer干掉→主进程重启子进程。
立刻验证监听状态：ss -tuln | grep :你的端口，输出中必须含*:端口号或0.0.0.0:端口号才算生效；若仍显示127.0.0.1:端口号，说明代码未生效或被其他配置覆盖。
防火墙/云安全组未放行端口也会造成类似症状
本地telnet 127.0.0.1 端口通 ≠ 外部能连，loopback流量不经过firewalld或云安全组；必须在云控制台安全组规则中添加入方向TCP规则，源IP暂设0.0.0.0/0测试。
Supervisor反复启动失败触发FATAL状态
① 运行php start.php start前台启动，紧盯终端输出——所有Fatal Error堆栈都会直接打印，这是最真实的第一手线索。
② 查看Supervisor日志：tail -f /var/log/supervisor/workerman-stdout.log，若连续三次启动失败，Supervisor会标记FATAL并放弃，此时真因是start.php本身语法错、扩展缺失或pidFile不可写，而非Worker逻辑问题。
③ 关键检查项：php -i | grep disable_functions 和 php -m | grep -E "pcntl|posix|sockets"，任一缺失都足以让Workerman无法初始化。
