Webman 默认信号机制不适用视频流场景，因其基于Swoole事件循环会接管pcntl_signal导致SIGTERM等信号被忽略或延迟，无法及时释放FFmpeg子进程、SSE连接和文件句柄，引发崩溃、端口占用及僵尸进程。
Webman 本身不直接暴露信号处理接口，swoole_process 和 pcntl_signal 在常驻进程模型中极易失效或被覆盖——这是视频流媒体服务在高负载下意外崩溃却无日志、无法优雅退出的根本原因。
为什么 Webman 的默认信号机制对视频流场景不适用
Webman 基于 Workerman/Swoole 运行，所有 Worker 进程由主进程 fork 启动，但 Swoole 的事件循环会接管 pcntl_signal，导致 PHP 层注册的信号处理器（如 SIGTERM、SIGHUP）被忽略或延迟响应。视频流服务常需长时间持有文件句柄、FFmpeg 子进程、SSE 连接等资源，若信号未被及时捕获，kill -15 可能只终止主进程，Worker 仍在后台运行并泄漏连接与内存。
常见错误现象：
- 执行
php start.php stop后，ps aux | grep webman仍看到残留的worker进程 - 重启服务时，端口被占用报错
Address already in use - FFmpeg 转码子进程变成僵尸进程（
Z+状态），top中看不到但ps aux | grep defunct可见
用 swoole_process::signal() 替代 pcntl_signal()
Swoole 提供了协程安全、事件循环兼容的信号注册方式，必须在 Worker 进程启动后、业务逻辑开始前调用，且仅对当前进程生效。
实操建议：
- 在
app/Bootstrap.php或自定义WorkerStart回调中注册，不要放在控制器或中间件里 - 只监听
SIGTERM（停止）、SIGUSR1（重载日志）、SIGUSR2（热重启），避免捕获SIGKILL或SIGSTOP - 每个信号处理函数内必须调用
swoole_process::exit()或显式关闭流式资源（如$response->end()、proc_terminate()）
示例（在 start.php 的 WorkerStart 钩子中）：
Webman 2.2.0版本强化了 TCP/UDP 服务支持，优化路由组管理，并增强异步任务处理能力。结合协程与连接池技术，Webman 能轻松应对高并发场景，适用于网站、接口服务、即时通讯、物联网及游戏开发，兼具高性能、灵活扩展与稳定可靠，是多场景 PHP 服务开发的理想选择。
Worker::onWorkerStart = function (Worker $worker) {
if ($worker->id === 0) {
// 主 Worker 示例：监听 SIGUSR2 做热重载
swoole_process::signal(SIGUSR2, function ($sig) {
echo "Received SIGUSR2, reloading...\n";
// 关闭所有活跃 SSE 连接
foreach (Context::get('sse_connections') as $conn) {
$conn->close();
}
// 重新加载配置、重置 FFmpeg 进程池
Config::reload();
FfmpegPool::reset();
});
}
};
视频流场景下必须手动释放的三类资源
信号到来时，不能依赖 PHP 自动析构——尤其在协程环境下，__destruct 可能永不触发。
必须显式清理：
-
子进程：用
proc_open()启动的 FFmpeg 必须配对调用proc_terminate($proc)+proc_close($proc)，否则子进程持续占用 CPU 和句柄 -
SSE 连接：Webman 中通过
$response->write()持续推送的连接，需在信号处理器中遍历保存的Response实例并调用$response->end() -
临时文件句柄：如使用
fopen('php://temp')缓冲视频帧，需调用fclose()；若用tmpfile()，也需提前fflush()并fclose()，否则磁盘空间缓慢泄漏
验证信号是否真正生效的两个命令
别只信日志——要看到进程状态变化才算数。
检查点：
- 向主 Worker 发送信号：
kill -USR2 $(cat runtime/master.pid)，然后tail -f runtime/log/webman.log查看是否打印 “reloading…” - 查看子进程是否退出：
ps --ppid $(cat runtime/master.pid) -o pid,comm，确认 FFmpeg 进程不再出现在列表中
最容易被忽略的是：Swoole 的信号注册是 per-process 的，你必须确保在每个需要响应信号的 Worker 里都调用了 swoole_process::signal()，而不是只在主进程或第一个 Worker 中注册。视频流服务往往开启多个 Worker 处理并发连接，漏掉任意一个，就可能留下“幽灵进程”。
