PHP-FPM 在致命的 php 错误后提供空白页面答案

【问题标题】：PHP-FPM serving blank pages after fatal php errorPHP-FPM 在致命的 php 错误后提供空白页面
【发布时间】：2013-06-01 00:55:54
【问题描述】：

我在 Arch linux 上有一个自定义的 nginx 和 php-fpm 设置。我将在下面发布我的配置。我想我现在已经从前到后阅读了这两个程序的文档大约 6 次，但是我已经到了无法从系统中挤出更多信息的地步，因此没有任何东西可以谷歌搜索。这是瘦的：

我从头开始编译了 nginx 和 php（我对此非常熟悉，所以大概没有问题）。我已经将 nginx 设置为正确地提供服务，它始终如一地做到这一点：php 文件通过 unix 套接字传递（对于 http 用户来说，它既存在又读/写可访问，这是 nginx 和php-fpm 运行方式），同时提供存在的常规文件。对文件夹的调用和对不存在的文件的调用都发送到/index.php 文件。所有权限都按顺序排列。

问题

在出现 php 错误之前，我的页面可以正常运行。错误被转储到 nginx 的错误日志中，并且来自 php-fpm 的特定子进程的所有进一步页面请求都返回空白。它们确实似乎已被处理，这可以从以下事实证明：随后对有错误的文件的调用继续将错误消息转储到日志文件中，但有缺陷的文件和干净的文件都返回完全空白并带有200 状态码。

几乎更疯狂的是，我发现如果我只是坐在上面几分钟，有问题的 php-fpm 子进程不会死掉，但会在下一个进程中生成一个新进程无论如何都请求，并且新进程正确地为页面提供服务。从那时起，每隔一个请求都是空白的，而另一个请求恢复正常，大概是因为子进程轮流为请求提供服务。

我的测试如下：

// web directory listing:
mysite/
--index.php
--bad_file.php
--imgs/
----test.png
----test2.png

index.php:

<?php
  die('all cool');
?>

bad_file.php*：

<?php
  non_existent_function($called);
?>

* 注意：我之前发布了bad_file.php 以包含$forgetting_the_semicolon = true 行，但发现这实际上并没有产生我正在谈论的错误（这是一个简化的示例我现在已经在我自己的系统上实现了）。然而，上面的代码确实重现了错误，因为它会产生致命错误而不是解析错误。

从终端测试调用：

curl -i dev.mysite.com/              # "all cool"
curl -i dev.mysite.com/index.php     # Redirected to / by nginx
curl -i dev.mysite.com/imgs          # "all cool"
curl -i dev.mysite.com/imgs/test.png # returns test.png, printing gibberish
curl -i dev.mysite.com/nofile.php    # "all cool"
curl -i dev.mysite.com/bad_file.php  # blank, but error messages added to log
curl -i dev.mysite.com/              # blank! noooooooo!!
curl -i dev.mysite.com/              # still blank! noooooooo!!
#wait 5 or 6 minutes (not sure how many - probably corresponds to my php-fpm config)
curl -i dev.mysite.com/              # "all cool"
curl -i dev.mysite.com/              # blank!
curl -i dev.mysite.com/              # "all cool"
curl -i dev.mysite.com/              # blank!
#etc....

nginx.conf：

user  http;
worker_processes  1;

events {
    worker_connections  1024;
}


http {
    include       mime.types;
    default_type  text/plain;

    sendfile        on;
    keepalive_timeout  65;

    index /index.php;

    server {
        listen       127.0.0.1:80;
        server_name  dev.mysite.net;
        root /path/to/web/root;

        try_files /maintenance.html $uri @php;
        location = /index.php {
          return 301 /;
        }
        location ~ .php$ {
          include fastcgi_params;
          fastcgi_pass unix:/usr/local/php/var/run/php-fpm.sock;
          fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        }
        location @php {
            include        fastcgi_params;
            fastcgi_pass   unix:/usr/local/php/var/run/php-fpm.sock;
            fastcgi_param SCRIPT_FILENAME $document_root/index.php;
        }
    }
}

php-fpm.conf：

[global]
pid = run/php-fpm.pid
error_log = log/php-fpm.log
log_level = warning

[www]
user = http
group = http
listen = var/run/php-fpm.sock
listen.owner = http
listen.group = http
listen.mode = 0660

pm = dynamic
pm.max_children = 5
pm.start_servers = 1
pm.min_spare_servers = 1
pm.max_spare_servers = 3

根据要求提供 php.ini

总结

所有页面都按预期提供直到出现 php 错误，此时对特定 php-fpm 子进程的所有后续请求显然都已处理，但返回为完全空白页面。发生的错误会在 nginx 错误日志文件中报告并继续报告。

如果有人有任何想法，请向我提出。在我弄清楚这一点之前，我已经死在水中了。顺便说一句，如果有人知道 php-fpm 的合法文档来源，那也会有所帮助。 php-fpm.org 似乎几乎没用，php.net 的 fpm 文档也是如此。

谢谢！

【问题讨论】：

标签： nginx php

【解决方案1】：

从昨天开始我就一直在搞砸这个问题，看起来它实际上是一个输出缓冲的错误。在尝试了所有内容，阅读了所有内容，对此发疯后，我终于关闭了输出缓冲，它工作正常。我已经提交了错误报告here。

对于那些不知道的人，输出缓冲是 php.ini 中的一个设置，它可以防止 php 在收到输出后立即跨行发送输出。不是一个完全关键的功能。我将它从 4096 切换到关闭：

;php.ini:
...
;output_buffering = 4096
output_buffering = Off
...

希望这对其他人有帮助！

【讨论】：