workerman主动推送失败需分三层排查：框架日志（worker::$logfile）、php错误日志（error_log配置路径）、master进程日志（同级workerman.log），缺一不可；同时验证推送逻辑是否执行、关键函数是否被disable_functions禁用，以及worker进程是否存活。
Workerman主动推送信息失败时，日志分散在多个位置，必须按类型逐层排查：框架运行日志、PHP错误日志、应用自定义日志三者缺一不可，漏看任意一处都可能错过关键线索。
确认推送失败是否触发了Worker::log()
第一步：检查你的推送逻辑中是否调用了Worker::log()记录失败事件。例如：Worker::log("推送失败: {$client_id} 连接已断开");
如果写了这行代码，日志会写入Worker::$logFile指定的文件；没写就根本不会出现在Workerman日志里——【这是最容易被忽略的前提】。
第二步：打开你设置的Worker::$logFile路径（比如/var/log/workerman/app.log），用tail -f /var/log/workerman/app.log实时观察。注意：该路径必须是绝对路径，且PHP进程有写权限，否则日志静默丢弃。
查PHP原生错误日志（推送失败常因致命错误中断）
方法一：直接定位php.ini中的error_log配置项
php --ini → 找到加载的php.ini路径 → grep "error_log" /path/to/php.ini → 得到真实日志文件路径，如/var/log/php_errors.log
方法二：运行时动态获取（适用于无法修改php.ini的环境）
php -r "echo ini_get('error_log');" → 输出结果就是当前生效的错误日志路径
注意：若display_errors=Off（守护进程默认如此），所有Warning和Fatal error都不会打印到终端，只进error_log文件。推送失败若由call to undefined function curl_init()引发，就只会在这里留下痕迹。
抓取master进程退出日志（推送失败伴随进程崩溃时必看）
第一步：确认你是否在项目根目录下启动服务
Workerman master进程默认把自身状态日志写入同级目录的workerman.log（不是Worker::$logFile）。即使你设置了Worker::$logFile，master的“子进程异常退出”“信号接收失败”等事件仍只记在这里。
第二步：执行tail -f workerman.log
重点查找含exit with status 256或Segmentation fault的行——这说明推送过程中PHP子进程因禁用函数（如pcntl_fork被disable_functions拦截）或扩展崩溃而终止，推送自然中断。
第三步：验证disable_functions是否误杀关键函数
php -i | grep disable_functions → 若输出包含curl_exec、socket_write、pcntl_*，立即修正。这些函数被禁会导致HTTP/Socket推送直接失败，且不抛异常，只静默退出。
验证推送逻辑是否根本没执行到日志点
第一步：在推送代码最开头加一行硬写日志
file_put_contents('/tmp/push_debug.log', date('Y-m-d H:i:s') . " 推送开始\n", FILE_APPEND);
第二步：触发一次推送，然后立刻执行cat /tmp/push_debug.log
如果文件为空，说明推送入口根本没被调用——可能是定时器未注册、事件监听器绑定失败、或客户端连接ID已失效导致路由跳过。
第三步：检查Workerman状态确认Worker存活
php start.php status → 观察对应Worker的connections和status字段。若connections为0或status显示stopping，推送目标不存在，日志当然不会产生。
