Different nginx error reporting "Primary script unknown"

Keywords: Web Server PHP Nginx Unix sudo

Last night, I forgot to make any changes to the development environment, which led to nginx prompting "Primary script unknown" when debugging the interface today. In most cases, this is a very simple problem: script_filename error in nginx configuration. However, I checked my nginx configuration and found nothing wrong.

location ~ \.php$ {
        include fastcgi_params;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        fastcgi_pass 127.0.0.1:9000;
        #fastcgi_pass unix:/var/run/php5-fpm.sock;
        try_files $uri =404;
    }

At the same time, I also validated this configuration by adding the request file name to the access log format configuration of the http module and using this configuration in the sever module.

log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
                  '$status $body_bytes_sent "$http_referer" '
                  '"$http_user_agent" "$http_x_forwarded_for" $document_uri $request_filename';
access_log  "logs/frontapi.access.log" main;

The following is a printed log, which has been verified to be correct.

127.0.0.1 - - [18/Mar/2019:12:40:40 +0800] "GET /v1/product/search?category=2 HTTP/1.1" 404 27 "-" "PostmanRuntime/7.6.1" "-" /index.php /Users/xubandit/Documents/www/mmt/mmt-mall-php/frontapi/web/index.php
^C
xubanditdeMacBook-Pro:logs xubandit$ ll /Users/xubandit/Documents/www/mmt/mmt-mall-php/frontapi/web/index.php
-rwxr-xr-x  1 xubandit  staff  570  3  9 16:39 /Users/xubandit/Documents/www/mmt/mmt-mall-php/frontapi/web/index.php

Then we looked into the PHP code and found that the request did not come to the PHP code at all. That is to say, the problem was php-fpm. Then we thought about how to debug php-fpm and checked the log of php-fpm. We found that only the information of php-fpm master process was recorded in the log, and that the content of PHP processing in the sub-process was not logged.

Only process debugging can be done, but it is found that there is no strace tool under macos. Fortunately, there is an alternative dtruss.

xubanditdeMacBook-Pro:php-fpm.d xubandit$ sudo dtruss  -p 13735
dtrace: system integrity protection is on, some features will not be available

SYSCALL(args)          = return
poll(0x7FFEE3A437B0, 0x1, 0x1388)         = 1 0
getrusage(0x0, 0x7FFEE3A43670, 0x0)         = 0 0
getrusage(0xFFFFFFFFFFFFFFFF, 0x7FFEE3A43670, 0x0)         = 0 0
dtrace: error on enabled probe ID 2174 (ID 159: syscall::read:return): invalid kernel access in action #12 at DIF offset 68
dtrace: error on enabled probe ID 2174 (ID 159: syscall::read:return): invalid kernel access in action #12 at DIF offset 68
dtrace: error on enabled probe ID 2174 (ID 159: syscall::read:return): invalid kernel access in action #12 at DIF offset 68
dtrace: error on enabled probe ID 2174 (ID 159: syscall::read:return): invalid kernel access in action #12 at DIF offset 68
dtrace: error on enabled probe ID 2174 (ID 159: syscall::read:return): invalid kernel access in action #12 at DIF offset 68
lstat64("/Users/xubandit/Documents/www/mmt/mmt-mall-php/frontapi/web/index.php\0", 0x7FFEE3A52E30, 0x0)         = -1 Err#13
stat64("/Users/xubandit/Documents/www/mmt/mmt-mall-php/frontapi/web\0", 0x7FFEE3A53980, 0x0)         = -1 Err#13
stat64("/Users/xubandit/Documents/www/mmt/mmt-mall-php/frontapi\0", 0x7FFEE3A53980, 0x0)         = -1 Err#13
stat64("/Users/xubandit/Documents/www/mmt/mmt-mall-php\0", 0x7FFEE3A53980, 0x0)         = -1 Err#13
stat64("/Users/xubandit/Documents/www/mmt\0", 0x7FFEE3A53980, 0x0)         = -1 Err#13
stat64("/Users/xubandit/Documents/www\0", 0x7FFEE3A53980, 0x0)         = -1 Err#13
stat64("/Users/xubandit/Documents\0", 0x7FFEE3A53980, 0x0)         = 0 0
stat64("/Users/xubandit\0", 0x7FFEE3A53980, 0x0)         = 0 0
stat64("/Users\0", 0x7FFEE3A53980, 0x0)         = 0 0
stat64("\0", 0x7FFEE3A53980, 0x0)         = -1 Err#2

Through debugging, it is found that php-fpm normally receives the parameter of file, but the error is reported when accessing. Then check the configuration file and find that php-fpm is run by nobody:nobody user, and the owner of the file is xubandit:staff. There is a problem with access rights. Because it is my local computer, the user running php-fpm is changed to xubandit:staff. The problem is solved here.

tips: For strace's convenience, I modified the php-fpm configuration so that php-fpm only fork out a subprocess to handle all requests

pm.max_children = 1
pm.start_servers = 1
pm.min_spare_servers = 1
pm.max_spare_servers = 1

Posted by philip@hux.co.za on Mon, 18 Mar 2019 09:03:27 -0700