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