Linux 程序使用 STDOUT 打印日志导致程序“假死”？一次线上 Bug 的深度排查与解决

一、问题背景

最近在维护一个基于 Webman 框架的 PHP 后台服务时，突然收到报警：部分 API 接口无法访问。

具体表现为：

• 客户端请求 /pacs/setCheckEnd 和 /pacs/postPatientInfo 接口时，连接被服务器直接中断。
• 无任何 HTTP 响应码（如 500、404），浏览器或 curl 显示为 ")Empty reply from server"。
• 其他接口正常，数据库查询也正常执行。
• 重启服务、更换端口、升级 Webman 版本均无效。
• 服务日志中没有任何错误输出，仿佛请求从未到达。

这个"静默崩溃"的现象非常可疑------没有报错信息，说明问题可能出在更底层。

---

二、初步排查过程

1. 验证网络与路由

首先确认是否是 Nginx 或反向代理的问题：

curl http://localhost:8787/pacs/setCheckEnd

结果依然是：

curl: (56) ) Empty reply from server

排除了 Nginx 层面的问题，确定是 Webman 自身的问题。

2. 检查代码逻辑和 SQL

查看该接口涉及的业务逻辑，发现其会构建并执行一条 SQL：

UPDATE ... WHERE ...

手动执行该 SQL，完全没问题。说明不是数据库层面的问题。

3. 查看日志 ------ 关键线索缺失

Webman 默认将日志打印到控制台（STDOUT）。但此时无论怎么触发请求，日志文件和终端都没有任何输出。

这就很奇怪了：请求明明进来了，为什么连最基础的 echo "start" 都不输出？

---

三、发现问题的关键突破口

尝试启动 Webman 服务时不带任何重定向：

php start.php start

然后通过 curl 发起请求，发现终端卡住！整个进程不再响应新请求，必须用 Ctrl+C 强制终止。

而当我改为：

php start.php start > /dev/null 2>&1 &

或将输出重定向到日志文件后：

php start.php start >> webman.log 2>&1 &

所有接口恢复正常，curl 能成功返回数据！

📌 结论浮出水面：只要不重定向 STDOUT，程序就会"假死"！

---

四、深入分析：为什么 STDOUT 导致程序挂起？

1. Linux 控制终端机制简述

当一个进程在 Linux 中以后台方式运行（如通过 systemd、nohup 或直接 & 启动），但它仍然试图向 标准输出（STDOUT）或标准错误（STDERR） 写入内容时，如果这些流所关联的终端已经关闭或不可写，就可能出现以下几种情况：

• 输出被丢弃（理想情况）
• 进程收到信号并暂停（常见于作业控制场景）

2. SIGTTOU 信号：罪魁祸首！

经过进一步查阅资料和测试，我们怀疑是 SIGTTOU 信号导致进程被挂起。

什么是 SIGTTOU？

• 当一个后台进程组 尝试写入其控制终端时，系统会发送 SIGTTOU 信号给该进程。
• 默认行为是 停止该进程（stop） ，使其进入 Stopped 状态。
• 此时进程并未退出，而是"卡住"，看起来就像"假死"。

可以通过 ps 查看状态：

ps aux | grep php

输出可能看到：

user    12345  T  0.0  1.2 123456 7890  ?   Sl   18:30   0:00 php start.php start

注意这里的 T 状态：表示进程已被暂停（stopped）。

这正是我们遇到的情况！

3. 为什么只影响某些接口？

因为只有特定接口中有较多的日志输出（例如 var_dump()、echo、框架自动打印 SQL 等），而其他接口较轻量，未触发大量输出，所以表现正常。

---

五、验证实验：本地复现 SIGTTOU

为了验证猜想，我们在办公室环境中进行了如下测试：

实验环境

• Ubuntu 20.04 LTS
• PHP CLI 模式运行脚本
• 使用普通用户启动进程，并断开终端

测试脚本 test.php

<?php
while (true) {
    echo "Hello, World\n";
    sleep(1);
}

复现步骤

1. 打开终端，运行：

   php test.php &

2. 断开 SSH 连接（或关闭终端）

3. 再次登录，查看进程状态：

   ps aux | grep php

   输出：

   user  12345  T  0.0  1.1 123456 7890  ?  Sl   18:30   0:00 php test.php

   T 状态出现！进程已停止。

4. 使用 kill -CONT 12345 恢复进程，它又能继续输出。

✅ 成功复现！

---

六、解决方案：始终重定向输出（推荐）

启动服务时务必重定向 STDOUT 和 STDERR：

php start.php start >> /var/log/webman/app.log 2>&1 &

或者使用 nohup：

nohup php start.php start > webman.log 2>&1 &

这样即使终端断开，也不会触发 SIGTTOU。

---

七、实践总结

项目	建议
日志输出	绝对不要依赖 echo, print, var_dump 打印生产日志
启动命令	必须重定向 > log.txt 2>&1 & 或使用 nohup
守护进程	设置 'daemonize' => true
日志系统	使用 Monolog、ThinkPHP Log 等支持文件/rotate 的组件
调试技巧	生产环境禁用 display_errors，通过日志定位问题

---

八、延伸思考：你真的了解你的输出流向吗？

很多开发者习惯在调试时用 echo "here" 来判断流程，但在以下场景中，这种做法极其危险：

• systemd 服务
• Docker 容器
• crontab 定时任务
• nohup 启动的后台进程

一旦主进程失去控制终端，每一次 echo 都可能成为压垮骆驼的最后一根稻草。

记住一句话：

在后台运行的程序，所有输出都必须有归宿------要么重定向到文件，要么交给日志系统处理。

---

九、结语

这次线上事故虽然最终解决方式简单（加个重定向），但背后涉及到的操作系统原理值得深思。看似"无症状"的假死，实则是 Linux 作业控制机制在默默起作用。

作为后端开发者，不仅要懂业务逻辑，更要理解程序运行的底层环境。一次小小的 echo，也可能引发雪崩式的故障。

希望这篇文章能帮你避开类似的坑。如果你也在用 Webman 或其他常驻内存的 PHP 框架，请务必检查你的启动方式和日志策略！