如何排查Linux php-fpm的错误

Linux 上排查 PHP-FPM 错误的实用流程

遇到 PHP-FPM 报错，别急着重启服务。一套清晰的排查思路，往往比盲目操作更能解决问题。下面这个流程，是许多运维老手在实践中总结出来的，能帮你快速定位并解决大多数 PHP-FPM 的常见故障。

一 快速定位思路

排查时，建议遵循一个由表及里、从现象到根源的步骤：

• 先看状态与日志：第一时间确认服务是否真的在运行，最近的日志里有没有明显的报错或权限问题。
• 再做基础检查：验证配置文件语法是否正确，端口或套接字是否被意外占用，排除那些导致服务“起不来”的直接原因。
• 联动上下游分析：结合 Web 服务器（如 Nginx）的错误日志和 PHP-FPM 自身的日志，交叉对比，判断问题是出在网关通信上，还是 FPM 进程内部。
• 最后专项处理：针对具体的错误表现，比如 502/504、空白页、脚本执行慢等，进行针对性的参数调整和优化。

二 定位步骤与命令

思路清晰了，接下来就是具体的操作命令。按这个顺序来，基本不会漏掉关键信息。

• 查看服务状态与日志
  • 状态检查：sudo systemctl status php-fpm。这个命令会告诉你服务是否活跃（active），是否失败（failed），并附上最近的系统日志片段，这是第一手信息。
  • 实时日志：sudo journalctl -u php-fpm -f。如果你想盯着看发生了什么，用这个命令可以实时追踪日志输出。
  • 定位错误日志：FPM 的错误日志路径可能因发行版和配置而异。常见位置有 /var/log/php-fpm.log、/var/log/php-fpm.log 或 /var/log/php-fpm/error.log。如果没单独配置，错误可能会打到系统日志（如 /var/log/syslog）里。最准确的方法是直接查看 www.conf 配置文件中的 error_log 指令。
• 配置语法与包含文件检查
  • 语法校验：sudo php-fpm -t。这个命令非常关键，它会检查主配置文件以及所有被包含的 pool.d/*.conf 文件是否存在语法错误，能避免很多因手误导致的启动失败。
• 进程与端口/套接字冲突
  • 端口占用（TCP模式）：sudo ss -tulnp | grep 9000。如果 FPM 配置为监听如 127.0.0.1:9000 这样的 TCP 端口，这个命令能帮你确认该端口是否已被其他进程占用。
  • 套接字文件（Unix Socket模式）：ls -l /run/php/php-fpm.sock。如果使用 Socket 方式，检查这个文件是否存在，并且其权限是否允许 Web 服务器进程（如 www-data）进行读写。
• 与 Web 服务器联动核对
  • 关键参数匹配：这是 502 错误的“高发区”。务必确保 Nginx 配置中的 fastcgi_pass 指令（例如 fastcgi_pass 127.0.0.1:9000; 或 fastcgi_pass unix:/run/php/...sock;）与 PHP-FPM 配置中的 listen 指令完全一致。同时，fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; 这一行也至关重要，它决定了 PHP 脚本的路径是否正确传递。
  • 交叉验证：当访问页面出现错误时，同时打开 Nginx/Apache 的错误日志和 PHP-FPM 的错误日志进行对比。如果 Web 服务器日志显示连接被拒绝，问题可能在通信层面；如果请求成功到达了 FPM 但 FPM 日志报错，那问题就出在 PHP 脚本或 FPM 配置本身。

三 常见症状与处理要点

不同的错误现象，指向不同的根源。下面这个表格整理了最常见的几种症状及其应对思路，可以帮你快速缩小排查范围。

以上要点可以作为一张检查清单，结合具体的日志信息和配置项，逐项验证和修复。

四 配置与权限检查清单

很多时候，问题就藏在配置文件和权限设置里。在深入排查前，不妨先按这个清单过一遍。

• 主配置与进程池
  • 主配置文件：通常是 /etc/php//fpm/php-fpm.conf，关注全局设置如错误日志路径(error_log)和日志级别(log_level)。
  • 进程池配置：通常是 /etc/php//fpm/pool.d/www.conf，这是核心，需要检查监听方式(listen)、运行用户(user/group)、进程管理策略(pm)、超时设置(request_terminate_timeout)、慢日志(slowlog)和文件描述符限制(rlimit_files)等。
• 监听方式一致性
  • TCP 模式：确保 FPM 的 listen = 127.0.0.1:9000 与 Nginx 的 fastcgi_pass 127.0.0.1:9000; 完全对应。
  • Unix Socket 模式：确保 FPM 的 listen = /run/php/php-fpm.sock 与 Nginx 的 fastcgi_pass unix:/run/php/php-fpm.sock; 路径完全一致。
• 权限与目录
  • 确保网站根目录（如 /var/www/html）和日志目录（如 /var/log/php-fpm）对运行用户（通常是 www-data）可读写：chown -R www-data:www-data /var/www/html /var/log/php-fpm。
  • 对于 Unix Socket 方式，要确保 Socket 文件所在的目录（如 /run/php）以及文件本身的权限正确，避免出现 “13: Permission denied” 错误。
• 日志可达
  • 如果你在配置中自定义了 error_log 路径，一定要先确认这个目录是否存在，并且 PHP-FPM 进程有写入权限。一个好习惯是：先创建目录并设置好属主权限，再重启服务。

五 进阶排查工具

当常规手段无法定位复杂问题时，这些进阶工具就能派上用场了。

• 慢脚本定位：在 www.conf 中开启 slowlog 并设置 request_slowlog_timeout（例如2秒）。当脚本执行超过这个时间，其完整的调用栈信息就会被记录到慢日志中，这对于分析性能瓶颈和慢 SQL 查询极其有效。
• 进程跟踪：如果遇到 FPM 子进程异常退出或卡死，可以使用 strace -f -ff -t -d -p 命令附着到可疑的进程 PID 上。它会输出进程所有的系统调用，能帮你精确定位到程序在哪个环节卡住或崩溃。
• 动态调参与热重启：根据监控数据，动态调整进程管理（pm）策略和子进程数量。在需要重启 FPM 加载新配置时，使用 sudo systemctl reload php-fpm 或向主进程发送 USR2 信号（kill -USR2 ）进行优雅重启，可以实现平滑重载，减少对线上服务的影响。