当前位置：首页 > news >正文

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

news 2025/9/28 6:00:52

一、问题背景

最近在维护一个基于 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);
}

复现步骤

打开终端，运行：
```
php test.php &
```
断开 SSH 连接（或关闭终端）

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

ps aux | grep php

输出：

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

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

使用 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`，通过日志定位问题