排查lighttpd环境下无日志的PHP崩溃问题

从你提供的lighttpd错误日志来看，核心问题是php-fpm worker进程异常退出，导致lighttpd与Unix Socket /var/run/php-fpm/www.sock 的连接失效；数分钟后自动恢复是因为php-fpm守护进程触发了自动重启机制。以下是具体排查方向：

1. 开启PHP-FPM崩溃日志与Core Dump #

当前未生成崩溃日志，先确保相关配置正确：

• 编辑/etc/php-fpm.conf，确认：
  • error_log = /var/log/php-fpm/error.log（路径正确且php-fpm进程有写入权限）
  • catch_workers_output = yes（捕获worker进程输出到错误日志）
  • emergency_restart_threshold 和 emergency_restart_interval：这两个参数控制php-fpm在指定时间内、达到多少进程崩溃时触发自动重启，可调整阈值延长重启间隔，方便抓取崩溃现场。
• 开启Linux Core Dump：
  • 在php-fpm的systemd服务文件（如/etc/systemd/system/php-fpm.service）中添加LimitCORE=infinity，执行systemctl daemon-reload && systemctl restart php-fpm
  • 或临时执行ulimit -c unlimited后重启php-fpm，进程崩溃时会在当前工作目录生成core.<pid>文件，后续用gdb /usr/sbin/php-fpm core.<pid>分析崩溃调用栈。

2. 监控PHP-FPM运行状态 #

开启php-fpm状态页面，实时跟踪进程变化：

• 编辑/etc/php-fpm.d/www.conf，设置pm.status_path = /status
• 在lighttpd配置中添加访问规则：

  $HTTP["url"] =~ "^/status$" {
    fastcgi.server = ( "" => ((
      "socket" => "/var/run/php-fpm/www.sock",
      "check-local" => "disable"
    )))
  }
  

• 重启lighttpd和php-fpm后，访问http://your-server/status，查看当前worker进程数、空闲进程数、请求处理数等指标，对比崩溃前后数据，判断是单个worker崩溃还是批量退出。

3. 定位触发崩溃的请求 #

随机崩溃大概率由特定请求触发：

• 调整lighttpd的access日志配置，记录完整请求信息：

  accesslog.format = "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\" \"%{X-Forwarded-For}i\""
  

• 崩溃发生时，对应时间点的access日志条目就是可疑请求，复制URL和参数本地复现测试。
• 用strace跟踪php-fpm worker进程：

  # 找到worker进程ID
  ps aux | grep php-fpm
  # 跟踪指定进程，输出到日志
  strace -p <worker-pid> -o /tmp/php-fpm-strace.log -s 1024
  

  崩溃后查看strace.log，最后几行的系统调用可暴露问题（如内存访问错误、异常系统函数调用）。

4. 检查系统资源与OOM Killer #

排除资源耗尽导致进程被杀：

• 查看系统日志/var/log/messages或dmesg，搜索Out of memory或Killed process，确认是否php-fpm进程被OOM Killer杀掉。
• 检查php-fpm配置pm.max_children、pm.start_servers是否合理：比如每个php-fpm进程占用50MB内存，16GB内存的服务器pm.max_children建议不超过300。
• 检查系统资源限制：执行ulimit -a，确认max user processes、open files是否足够，不足的话在/etc/security/limits.conf中调整。

5. 排查PHP代码与扩展问题 #

• 禁用非必要PHP扩展：注释php.ini中不需要的扩展，逐个恢复，看崩溃是否复现，定位有问题的扩展（php7.4部分旧版扩展存在内存泄漏或崩溃BUG）。
• 代码层面监控：在可疑业务代码中添加内存日志：

  error_log("Memory usage: " . memory_get_usage(true) . " | Peak: " . memory_get_peak_usage(true));
  

  或用tideways等工具跟踪代码执行，找出内存泄漏或死循环位置。

6. 系统层面排查 #

• 检查Rocky Linux系统更新记录，看崩溃是否发生在某次内核或glibc更新之后，必要时回滚测试。
• 实时监控服务器负载：用top、vmstat 1、iostat 1观察CPU、内存、磁盘IO变化，确认崩溃时是否有资源突增情况。

内容的提问来源于stack exchange，提问作者QldRobbo