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

时间:2013-06-01 00:55:54

标签: nginx php

我在arch linux上有一个自定义的nginx和php-fpm设置。我将在下面发布我的配置。我想我现在已经阅读了这两个程序的文档,从现在开始大约6次,但是我已经达到了这样的程度,我根本无法从系统中挤出任何更多的信息,因此没有任何东西留给谷歌。这是瘦的:

我从头开始编译nginx和php(我对此非常熟悉,所以可能没有问题)。我已经设置了nginx以正确地提供服务,它始终如一地执行:php文件通过unix套接字传递(对于http用户来说,它既是存在的,也是可读/可写的,这是nginx和nginx的用户php-fpm run as),而现有的常规文件得到服务。调用文件夹和调用不存在的文件都发送到/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文档一样。

谢谢!

1 个答案:

答案 0 :(得分:3)

自从昨天以来我一直在搞乱它,看起来它实际上是输出缓冲的一个错误。在尝试了一切之后,阅读所有内容,对它疯狂,我终于关闭了输出缓冲,它运行良好。我已提交错误报告here

对于那些不知道的人,输出缓冲是php.ini中的一个设置,它阻止php在收到输出后立即通过线路发送输出。不是一个完全关键的功能。我将它从4096切换到关闭:

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

希望这有助于其他人!