状态码256表明PHP子进程因致命错误（如禁用函数调用、扩展段错误）被内核强制终止，对应信号1，需检查core dump和禁用函数配置。
Workerman 进程退出状态码为 256，基本可以确定是 PHP 发生了致命错误（如扩展崩溃、段错误），而非业务代码 throw 的异常。
看 exit with status 256 就该查 core dump 和禁用函数
这个退出码不是 Workerman 自己定义的，而是 Linux 进程退出时由内核返回的：PHP 子进程因严重错误（比如调用了被禁用的函数、扩展 segfault）被强制终止，shell 层面收到的是 256（即 1 ，表示子进程以信号 1 退出，但更常见的是 PHP 崩溃后返回 256，等价于 coredump）。
- 先运行
curl -Ss http://www.workerman.net/check.php | php—— 它会检测pcntl、posix、sockets是否启用，还会报出哪些函数被disable_functions拦住了（比如pcntl_fork、posix_kill被禁会导致 master 无法管理 worker，直接退出） - 检查 PHP 配置：
php -i | grep disable_functions，重点确认pcntl_*和posix_*系列没被禁 - 如果服务器开了 core dump，去
/proc/sys/kernel/core_pattern看路径，找对应 core 文件，用gdb php core.xxx查崩溃点（但多数生产环境关了这个）
日志里找不到 error？那就得开 Config::$debug = true + error_reporting(E_ALL)
Workerman 默认不把 PHP 错误打到 stdout，尤其在守护进程模式下，display_errors=Off 会让所有 warning/fatal 消失得干干净净。
- 在
start.php顶部加两行：ini_set('display_errors', 'on'); error_reporting(E_ALL); - 紧接着加上：
use Workerman\Config; Config::$debug = true;—— 这能让 Workerman 输出 worker 启动/退出、信号接收、重载等内部动作 - 别依赖
var_dump()或echo：它们输出位置不可控，容易和 Workerman 自身日志混在一起；改用file_put_contents('/tmp/debug.log', "xxx\n", FILE_APPEND);更稳 - 注意：
Config::$debug在新版中主要影响框架行为日志（如 “worker xxx started”），业务逻辑报错仍靠 PHP 原生错误机制
master 进程退出 ≠ worker 异常，要看 ps aux | grep start.php 和 tail -f workerman.log
Workerman 是 master-worker 模型，master 退出整个服务就挂了，但 worker 退出可能只是某个子进程崩了——这两者日志位置、排查路径完全不同。
- master 日志默认写入
workerman.log（同级目录），内容包括启动、reload、stop、子进程异常退出事件；worker 日志默认不落盘，除非你显式调用Worker::log()或自己写文件 - 用
ps aux | grep start.php看进程树：如果只剩一个 master 进程（无 worker），说明 worker 全挂了或根本没起来；如果连 master 都没了，大概率是启动脚本第一行就 fatal error 了（比如require缺文件） - 宝塔用户特别注意：面板里“运行”按钮起的服务，实际是以面板用户身份跑的，很可能没权限读配置、连端口、fork 进程 —— 务必切到命令行用
php start.php start -d手动试一次
真正卡住人的地方，往往不是日志没开，而是日志写到了你看不到的地方：比如 workerman.log 被写进了 root 目录、error_log 走了 php-fpm 的配置、或者容器里 /tmp 不可写导致 file_put_contents 失败。动手前，先确认「日志到底有没有产生」，比猜原因快得多。
