PHP-FPM serves for blank pages after a fatal php error

I have a custom configuration of nginx and php-fpm in arch linux. I will talk about my configurations below. I think I read the documentation for these two programs from front to back about 6 times, but I reached a point where I simply can’t get more information out of the system and therefore I have nothing left from Google. Here's the skinny one:

I compiled nginx and php from scratch (I am very familiar with this, so there seems to be no problem). I have nginx to properly service things that happen sequentially: php files go through a unix socket (which is present and read and write for the http user, who is a user who is both nginx and nginx php-fpm run as) while regular files that exist are maintained. Calls for folders and calls for files that do not exist are sent to the /index.php file. All permissions are in order.

Problem

My pages are served just fine until a php error appears. The error is uploaded to the nginx error log, and all further requests for pages from this particular php-fpm child process return empty. They look like do , as evidenced by the fact that subsequent accesses to the file with errors continue to produce error messages in the log file, but both erroneous and clean files are returned completely empty with 200.

What I found a little dumber than if I was sitting on it for several minutes, the abusive php-fpm child process does not die, but in any case a new request is generated in the next request, and the new process serves the pages correctly. From this point on, every second request is empty, while the other request returns normal, apparently because the child processes process service requests.

My test is as follows:

 // 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); ?> 

* Note. I previously posted bad_file.php to contain the string $forgetting_the_semicolon = true , but found that this did not actually result in the error I'm talking about (this was a simplified example that I now implemented on my own system). However, the above code executes when it causes a fatal error instead of a parsing error.

test calls from the terminal:

 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 on request

In summary

All pages are served as expected until the php error occurs, after which all subsequent requests to this particular process of the php-fpm child processes are apparently processed, but returned as completely empty pages. Errors that occur are reported and continue to be reported in the nginx error log file.

If anyone has any ideas, drop them on me. I'm dead in the water until I find out. By the way, if someone knows the source of legitimate documentation for php-fpm, that would also be helpful. php-fpm.org seems almost useless, like the php.net documentation for fpm.

Thanks!

+4
source share
1 answer

I have been messing around with this since yesterday, and it looks like this is actually an error with output buffering. After trying everything, reading everything, losing my mind, I finally turned off output buffering, and it worked fine. I sent an error report here .

For those who don’t know, output buffering is a parameter in php.ini that prevents php from passing through a string immediately after receiving it. Not a very important feature. I switched it from 4096 to Off:

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

Hope this helps someone else!

+3
source

Source: https://habr.com/ru/post/1483893/


All Articles