“master process exited”主因是前台模式被sighup终止，需加-d守护并确保pidfile为绝对路径且目录可写；其次检查disable_functions禁用pcntl_fork/posix_kill、php致命错误及supervisor重试掩盖问题。
看到“master process exited”先确认是不是前台模式被终端杀掉了
Workerman 默认不 daemonize，php start.php start 启动的是前台进程，SSH 断开或终端关闭会触发 SIGHUP，整个进程树直接退出——这不是错误，是行为预期。现象就是“刚启就退”，日志里可能连一条记录都没有。
必须加 -d 参数启用守护模式：php start.php start -d。但注意：它不会报错告诉你失败了。如果 $worker->pidFile 路径不可写、不是绝对路径、或父目录不存在，-d 会静默失败，几秒后 master 自动退出，看起来一模一样。
-
$worker->pidFile必须设为绝对路径，例如/var/run/workerman.pid，不能是workerman.pid - 运行用户（如
www-data）需对 pidFile 所在目录有写权限：mkdir -p /var/run && chown www-data:www-data /var/run - 别用
nohup php start.php start &—— Workerman 没处理SIGHUP，子进程仍可能中断
status 256 就该查 PHP 崩溃，不是 Workerman 逻辑问题
日志里出现 exit with status 256，基本等于 PHP 子进程发生了致命错误：调用了被禁函数（如 pcntl_fork）、扩展段错误（segfault）、或内存越界。这个 256 是 Linux 内核返回的，等价于信号 1（SIGHUP）或更常见的是崩溃后未生成 core 的 fallback 状态。
最该先跑的命令是：curl -Ss http://www.workerman.net/check.php | php。它会明确指出哪些必需函数被 disable_functions 拦住了——尤其是 pcntl_fork 和 posix_kill，这两个一被禁，master 根本无法 fork worker，必然闪退。
- 检查禁用函数：
php -i | grep disable_functions - 确认关键扩展已启用：
php -m | grep -E "pcntl|posix|sockets" - 若开了 core dump，查
/proc/sys/kernel/core_pattern路径，用gdb php core.xxx定位崩溃点（但生产环境通常关了）
master 日志和 worker 日志完全不是一回事
master 进程退出 ≠ worker 异常。master 日志默认写入同级目录的 workerman.log，内容包括启动、reload、stop、子进程异常退出事件；而 worker 日志默认不落盘，除非你显式调用 Worker::log() 或自己写文件。
所以看到 master process exited，第一反应不该翻业务代码，而是立刻：tail -f workerman.log。如果日志为空或只有“Start success”，说明 master 根本没活过初始化阶段——大概率是配置语法错误、require 失败、或 Worker::runAll() 前就 fatal 了。
- 在
start.php开头加两行：ini_set('display_errors', 'on'); error_reporting(E_ALL);，否则 fatal 错误完全不落地 -
Config::$debug = true（新版中主要影响框架行为日志，如“worker xxx started”），但业务逻辑报错仍靠 PHP 原生机制 - 别依赖
echo或var_dump()：输出位置不可控，容易和 Workerman 自身日志混在一起；改用file_put_contents('/tmp/debug.log', "xxx\n", FILE_APPEND)更稳
Supervisor 报 FATAL 其实是启动失败三次以上
Supervisor 日志里出现 gave up: workerman entered FATAL state, too many start retries too quickly，说明 Workerman 主进程连续三次启动都失败了——比如配置语法错、端口被占、pidFile 不可写、或 disable_functions 拦了关键函数。Supervisor 主动放弃，不是它的问题。
此时不要急着调 Supervisor 配置，先脱离它单独运行：php start.php start -d，观察终端输出和 workerman.log。Supervisor 只是暴露了底层失败，不是根源。
- 检查
ps aux | grep start.php：如果连 master process 都看不到，说明根本没启动成功 - 用
ss -tuln | grep :端口验证内核监听状态：没输出＝master 没跑起来，或监听失败 - 确保
start.php中Worker::runAll()是最后一行，前面不能有 exit/return/die
