FPM starts but doesn't serve

[Ken Snyder]

I have successfully setup FPM on my OSX machine but when attempting to do the same on Ubuntu 14.04 I am experiencing a weird problem where:

• The server starts when I run php5-fpm. I can see the processes with ps -ef:

root        10     1  0 Sep16 ?        00:00:00 /bin/sh -c /usr/sbin/php-fpm -c /etc/php5/fpm/php.ini --fpm-config /etc/php5/fpm/php-fpm.conf

root        11    10  0 Sep16 ?        00:00:02 php-fpm: master process (/etc/php5/fpm/php-fpm.conf)                              

www-data    12    11  0 Sep16 ?        00:00:00 php-fpm: pool default                                                             

www-data    13    11  0 Sep16 ?        00:00:00 php-fpm: pool default                                                             

www-data    14    11  0 Sep16 ?        00:00:00 php-fpm: pool default                                                             

www-data    15    11  0 Sep16 ?        00:00:00 php-fpm: pool www                                                                 

www-data    16    11  0 Sep16 ?        00:00:00 php-fpm: pool www                                                                 

• I can telnet to the port specified (9000) in the pool configuration and there FPM does appear to be listening to this port
• Requesting any document (e.g., GET /, GET /status, GET /foobar) results in a disconnect (e.g., "Connection closed by foreign host")

Strangest of all is that doing this never results in the generation of a php_error.log file. In my php.ini file (which you can see I'm explicitly pointing to the shell command above) has the following entries regarding logs:

error_reporting = E_ALL & ~E_DEPRECATED & ~E_STRICT

display_errors = Off

display_startup_errors = Off

log_errors = On

log_errors_max_len = 1024

ignore_repeated_errors = Off

ignore_repeated_source = Off

report_memleaks = On

track_errors = Off

html_errors = On

These are pretty much bog-standard and if I were getting through to PHP I'd have thought I'd get something either as a PHP error or something in the FPM log. The FPM log, btw, simply states:

[16-Sep-2014 21:34:15] NOTICE: fpm is running, pid 11

[16-Sep-2014 21:34:15] NOTICE: ready to handle connections

I do find that a lot of the time these mysterious errors come down to file permissions and this is certainly a possibility here but I have checked and I think things are ok. In my php.ini file I specify a doc_root of /app/content and the file permissions look like this:

root@d7ebf59e2c13:/app# ll content

total 12

drwxr-xr-x  2 www-data www-data 4096 Sep 16 21:34 ./

drwxr-xr-x 14 www-data www-data 4096 Sep 16 21:34 ../

-rw-r--r--  1 www-data www-data   20 Sep 16 21:33 index.php

and in the pool configuration for FPM I have:

[default]

listen = 9000

user = www-data

group = www-data

One other variable of note, which I suspect is not a part of the problem, is that I'm running this in a Docker instance. I suspect it's not a problem both because I experience the behaviour precisely the same from within the container as I do from the host environment but also because running FPM in Docker seems to be very commonly done pattern. In any case I bring it up for full disclosure and the off chance that someone has a view why this might cause problems. 

Ken

[Peter Hicks]

Hi Ken

I have the same symptoms as you - this worked OK prior to a routine software update on an Ubuntu 14.04 box at the weekend, and hasn't worked since.

Even a simple PHP script with <?php touch('/tmp/flag.txt') ?> doesn't run.

I've done some further debugging, moved php-fpm over to using a TCP connection and I ran tcpdump to see the request and response - the request goes through OK, the headers of the response come back, but no body.

Peter

[Ken Snyder]

Peter,

I guess misery loves company so I'm happy to hear I'm not alone while at the same time disappointed that you've had to suffer along with me. I too switched between TCP and Unix sockets as part of my debugging but with no progress. I am happy, however, to announce that I have moved from one intractable problem to another. Some of this you may already know but what occurred to me after posting this is that FPM likely is binary interface and therefore my telnet test was bound to fail. That set me down the path of getting NGINX up and pointing it to FPM. This had some very moderate success but led to more frustration and an equally unacceptable stopping point for me. Rather than retype it all I have posted on StackOverflow here:

http://stackoverflow.com/questions/25973752/fpm-nginx-unable-to-open-primary-script/25975307?noredirect=1#comment40679744_25975307

It seems highly likely from this that NGINX and FPM are communicating although perplexingly there is still no php_error or php-fpm_error log. Very odd. Anyway, I say they are likely communicating because there is a clear behavioural distinction between requesting files that DO exist and those that do not and the NGINX log refers to the fast-cgi in stderr. Very interested to hear any progress you make and I will make sure to update this discussion too if I get anywhere. Today/tomorrow I'll be working on other unrelated stuff but then this becomes my biggest focus again.

[Peter Hicks]

Hi Ken

On Tuesday, 23 September 2014 16:42:05 UTC+1, Ken Snyder wrote:

 

It seems highly likely from this that NGINX and FPM are communicating although perplexingly there is still no php_error or php-fpm_error log. Very odd. Anyway, I say they are likely communicating because there is a clear behavioural distinction between requesting files that DO exist and those that do not and the NGINX log refers to the fast-cgi in stderr. Very interested to hear any progress you make and I will make sure to update this discussion too if I get anywhere. Today/tomorrow I'll be working on other unrelated stuff but then this becomes my biggest focus again.

That got me thinking - is this an NGINX problem rather than FPM or PHP... and then I found https://bugs.launchpad.net/nginx/+bug/1366651 - the solution appears straightforward and a case of adding a configuration statement.

Peter

[Ken Snyder]

Very interesting indeed. I will see if I can get in and test this again this morning. Because I'm using Docker in my non-test environments I can quite easily try with 1.6 and 1.7.x versions of NGINX as well as try the suggested fix. Have you given it a whirl yet?

Ken

[Peter Hicks]

On Wednesday, 24 September 2014 19:07:15 UTC+1, Ken Snyder wrote:

Very interesting indeed. I will see if I can get in and test this again this morning. Because I'm using Docker in my non-test environments I can quite easily try with 1.6 and 1.7.x versions of NGINX as well as try the suggested fix. Have you given it a whirl yet?

Yup - tried it this morning through NGINX and it worked straight off.

Peter