Troubleshooting PHP-FPM

[Beluga]

I first tried to run a (confirmed working on a traditional Apache setup) PW instance on Caddy + PHP-FPM. Failing that, I tried running it with Nginx + the same PHP-FPM. I got the same error. I describe the error in the Caddy topic.

As I get the exact same error both with Caddy and Nginx, everything else must be fine besides something with PHP-FPM.

It is not a general PHP-FPM problem, as a simple phpinfo file in the web root runs fine.

Here is my www.conf.

Here is my php-fpm.conf (never touched it).

Here is my php.ini.

Here is my php-fpm service file.

For the Nginx experiment, I used the server config from the Howtoforge PW on Nginx tut.

OS is Arch Linux.

I even asked help from the Caddy developers, including the one who provided the PW example config, but they were stumped.

Is debugging PHP-FPM really this hard: practically impossible? If you think of something, please comment.

[LostKobrakai]

Debugging php-fpm shouldn't be that hard. Enable the /status page in the www.conf and you can check all the calls made to php-fpm and everything afterwards should be debuggable like any other php installation as well (e.g. xdebug). Everything else is out of the scope of user debugging and the responsibility of the package maintainers imho.

About the error. Is that a fresh pw installation? Can you try manually including the missing class right before the error happens, so we can exclude any autoloading issues?

[Beluga]

It is not a fresh installation, it is a confirmed working installation.

I tried the /status page before, but was unable to get it working.

Now I searched for a more detailed example and found one.

I made several modification passes to get it "working" and now it displays a blank page for me.

Here is the modified block I added inside my server block:

location ~ ^/(status|ping)$ {
     #access_log off;
     allow 127.0.0.1;
     allow (my ip address);
     deny all;
     include /etc/nginx/fastcgi_params;
     fastcgi_pass unix:/var/run/php-fpm/php-fpm.sock;
}

I enabled php-fpm access.log. The default log configuration gives me this entry when I access /status and see the blank page:

- -  19/Mar/2016:23:42:27 +0200 "- " 200

Is there some recommended configuration with maximum info?

When I access /ping, it does not print "pong" like described in the comments of the status page tutorial.

So debugging php-fpm might not be hard, but now we are at a point where setting up the debugging method itself is proving hard

[LostKobrakai]

I've used this exact snippet yesterday, I'm just not sure if you're really on localhost, therefore for testing I'd remove the 2 allow … and the deny … lines. Also my experience with blank pages and still a 200 is, that fastcgi_params might not be correct / sufficient. 

[Beluga]

I've used this exact snippet yesterday, I'm just not sure if you're really on localhost, therefore for testing I'd remove the 2 allow … and the deny … lines. Also my experience with blank pages and still a 200 is, that fastcgi_params might not be correct / sufficient. 

Well it didn't deny me before (was not on localhost, had allowed my ip) and now I tried with the 3 lines commented out and same blankness.

I never touched the params, but here they are:

fastcgi_param  QUERY_STRING       $query_string;
fastcgi_param  REQUEST_METHOD     $request_method;
fastcgi_param  CONTENT_TYPE       $content_type;
fastcgi_param  CONTENT_LENGTH     $content_length;

fastcgi_param  SCRIPT_NAME        $fastcgi_script_name;
fastcgi_param  REQUEST_URI        $request_uri;
fastcgi_param  DOCUMENT_URI       $document_uri;
fastcgi_param  DOCUMENT_ROOT      $document_root;
fastcgi_param  SERVER_PROTOCOL    $server_protocol;
fastcgi_param  HTTPS              $https if_not_empty;

fastcgi_param  GATEWAY_INTERFACE  CGI/1.1;
fastcgi_param  SERVER_SOFTWARE    nginx/$nginx_version;

fastcgi_param  REMOTE_ADDR        $remote_addr;
fastcgi_param  REMOTE_PORT        $remote_port;
fastcgi_param  SERVER_ADDR        $server_addr;
fastcgi_param  SERVER_PORT        $server_port;
fastcgi_param  SERVER_NAME        $server_name;

# PHP only, required if PHP was built with --enable-force-cgi-redirect
fastcgi_param  REDIRECT_STATUS    200;

[Beluga]

Solved the blankness by adding this:

fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;

 

Status reads: 

pool:                 www
process manager:      dynamic
start time:           19/Mar/2016:23:41:47 +0200
start since:          41625
accepted conn:        5
listen queue:         0
max listen queue:     0
listen queue len:     0
idle processes:       1
active processes:     1
total processes:      2
max active processes: 1
max children reached: 0
slow requests:        0

[Beluga]

Can you try manually including the missing class right before the error happens, so we can exclude any autoloading issues?

I included the class (from wire/modules/Process/ProcessPageType/ProcessPageType.module) and now the complaint switched to:

Fatal error: Class 'InputfieldSubmit' not found in /var/www/sitename/pw/wire/modules/Inputfield/InputfieldButton.module on line 10

[Beluga]

Well, I made a fresh install of PW3 under Nginx and it worked ok, so it seems something must have gone wrong with the transferring of the old site

I did it with wget from OVH hosting ftp directly to the server. I will try again tomorrow, first downloading to my local machine.

PW3 did not work OK with Caddy, though (some glitches in the admin).. but under time constraints I have to focus on Nginx now and abandon Caddy.

Edit: confirmed that something went wrong the first time I transferred the site! I used wget and seems we cannot trust it to be reliable

Now the old site works with Nginx.

I am getting assistance from a forum user to get Caddy working.