跳转到主内容
极星编程网：以代码为星，赴技术山海！
📁 网站地图

Workerman运行过程中突然断开，日志没有任何报错怎么查？

苏承栈
苏承栈
• 👁 0人浏览过
状态码256表明PHP子进程因致命错误（如禁用函数调用、扩展段错误）被内核强制终止，对应信号1；需立即检查disable_functions（重点pcntl_fork、posix_kill）、运行官方检测脚本curl -Ss http://www.workerman.net/check.php | php，并确认log_errors=On且error_log路径可写。 Workerman 进程退出状态码 256 怎么看？ 看到
exit with status 256
就别翻业务日志了，这根本不是 PHP 异常，而是 PHP 子进程被内核强制终止（等价于收到信号 1 或发生段错误）。Workerman master 进程本身不崩溃，但所有 worker 都退出，服务就断了。 用
ps aux | grep start.php
确认 master 是否还在；如果没了，是 master 崩了；如果还在但没 worker 进程，就是 worker 全挂了 查
workerman.log
最末尾，找类似
Worker[xxx] exit with status 256
的记录 立刻运行
php -i | grep disable_functions
，重点盯
pcntl_fork
、
posix_kill
、
posix_getpid
—— 这些被禁，master 根本无法 fork 或管理 worker 跑一次
curl -Ss http://www.workerman.net/check.php | php
，它会直接告诉你哪些关键函数被拦住了 为什么 workerman .log 里啥都不写？ Workerman 默认不把 PHP 错误输出到日志文件，尤其在守护进程模式下：
display_errors=Off
+
error_reporting
不开 = 所有 fatal error、warning 全部静默消失。 在
start.php
开头紧贴
加两行：
error_reporting(E_ALL); ini_set('display_errors', 'on');
再加一行：
use Workerman\Config; Config::$debug = true;
—— 这能让 Workerman 自己打启动/退出/信号等内部动作 别用
echo
或
var_dump()
调试：它们输出位置不可控，容易被缓冲或混进系统日志；改用
file_put_contents('/tmp/workerman-debug.log', "xxx\n", FILE_APPEND)
确认
Worker::$logFile
指向的路径有写权限，且磁盘没满（
df -h
看一眼） 客户端连不上，但 ss -tuln 看不到监听端口怎么办？ 端口没监听 ≠ Workerman 启动失败，很可能是 worker 进程压根没起来。master 启动了，但 onWorkerStart 里抛了未捕获异常，worker 就直接退出，master 也不报错。 Workerman 最新主版本，继续强化高性能异步网络能力，适合 WebSocket、HTTP 服务、长连接、IM、IoT 等场景。 本次版本主要围绕稳定性、协议兼容以及连接处理能力优化，依旧保持超轻量和纯 PHP 特性。 适用于 PHP 8.x 环境，可配合 webman、GatewayWorker 等生态使用。 下载 先执行
ss -tuln | grep :你的端口
：没输出 = kernel 层根本没监听；只有
127.0.0.1:端口
= 绑定错了，得改成
tcp://0.0.0.0:端口
再跑
ps aux | grep WorkerMan
：只看到
master process
没有
worker process
，基本就是 onWorkerStart 出问题了 临时把
onWorkerStart
里逻辑注释掉，只留
Worker::log('ok')
，看 worker 能否稳定起来；能，就逐步放开代码定位哪行触发崩溃 检查是否用了
SO_REUSEADDR
，TIME_WAIT 太多导致 bind 失败 —— Workerman 不报错，但就是不监听，客户端连就 Connection refused 没有 core dump，怎么定位 PHP 扩展崩溃点？ 生产环境通常关了 core dump，但崩溃点其实还能从蛛丝马迹里找。 用
strace -f -e trace=clone,execve,openat,kill -p $(pgrep -f "start.php")
抓 worker 启动时的系统调用，看到
clone
成功但后续立刻
kill
自己，大概率是扩展初始化失败 临时换一个干净的 PHP 环境（比如 CLI 下单独跑
php -m
看有没有 segfault，或
php -v
是否卡住） 禁用可疑扩展：在 php.ini 里注释掉
extension=xxx.so
，尤其是刚升级过的 swoole、redis、grpc 等 C 扩展 如果用了 Docker，确认 base 镜像里
pcntl
和
posix
是编译进 PHP 的，不是动态加载 —— 很多 alpine 镜像默认不带 日志空、连接断、进程退——这些现象背后往往不是代码 bug，而是 PHP 运行时环境被悄悄掐住了脖子。最常被忽略的是
disable_functions
和
display_errors
的组合杀伤力，它能让一切错误彻底隐形。

相关文章