2014070221: 53: 02 [error] 4952 #0: * 8 FastCGIsentinstderr: enabled, client: 184.108.40.206, server: localhost, request: GETinfo. phpHTTP1.1, upstream: fastcgi: unix:
21:53:02 [error] 4952 #0: * 8 FastCGI sent in stderr: "Primary script unknown" while reading response header from upstr eam, client: 220.127.116.11, server: localhost, request: "GET/info. php HTTP/1.1 ", upstream:" fastcgi: // unix:
2014/07/02 21:53:02 [error] 4952#0: *8 FastCGI sent in stderr: "Primary script unknown" while reading response header from upstr eam, client: 18.104.22.168, server: localhost, request: "GET /info.php HTTP/1.1", upstream: "fastcgi://unix:/var/run/php5-fpm.sock:", host: "100.100.100.100"
Nginx + PHP: the PHP page is blank and the prompt "No input file specified" is displayed. The nginx error log shows "Primary script unknown ". This is actually an error reported by PHP when display_errors is set to off. When PHP is installed by default, errors are output to stderr or stdout, captured by nginx, and recorded in error. log. The root cause is that PHP cannot find the corresponding file that nginx tells it. Some causes can cause this problem, as shown below.
1. An incorrect path is passed to PHP.
Most of the reason is that beginners refer to google articles on the Internet for configuration. Nginx uses the fastcgi_param value of SCRIPT_FILENAME to tell PHP the file to be executed. Most articles on the Internet set the value of this parameter to $ document_root $ fastcgi_script_name. Sometimes this configuration is used to solve the "No input file specified" problem. However, this will cause the path to be "written to death". One day you will find the problem.
The reason is that nginx has three levels of configuration inheritance relationships: the three levels of blocks are http, server, and location, which are parent-child relationships. Commands in nginx configuration are inherited downward, but they are not inherited or crossed upwards. For example, if you define something in a location, it will not be applied to other locations.
Typical beginners define index and root in location/, because the articles on the Internet teach this. When $ document_root is used to define SCRIPT_FILENAME, root is not actually defined. Therefore, the value of SCRIPT_FILENAME is only changed to URI, and PHP cannot find the file.
A simple solution is to define root in the server or http block.
2. Incorrect File Permissions
Most people don't trust me when I tell him that your permission settings are incorrect. They stare at the permission settings of the script file. PHP users have read permission !? Unfortunately, this shows that he lacks understanding of Unix user permissions. The startup user of PHP not only needs the read permission of the script file, but also needs to be able to enter the directory (and upper-level directory) where the script file is located, which requires the PHP user to have the execution permission for these directories. For example:
You have an index in the/var/www directory. the php script file requires the PHP user to/var/www/index. php has the read permission and must have the execution permission on the/var and/var/www directories.
I met a newly installed Debian nginx + php environment. After adding a PHP user to the user group of the owner of the $ document_root directory, the permission does not take effect because php-fpm has not been restarted. I checked the cause for half a day.