This article mainly introduces Nginx when upgrading PHP from 5.3.28 to 5.3.29 A 502 error occurred, friends in need can refer to it
Today I upgraded PHP from 5.3.28 to 5.3.29 and found that the website cannot be opened, prompting "502 bad gateway". Accessing static resources is OK, but accessing any PHP file will result in 502.
In fact, I have discovered this problem before, but I have never found a solution, so I have always kept PHP at version 5.3.28.
According to my previous temper, I have to get the latest stable version of all software, but software such as PHP is an exception, because a higher version will cause many programs to be incompatible. Relatively speaking, 5.3 has the best compatibility. One of the versions, of course 5.2 is also available.
I really can’t bear the obsessive-compulsive disorder. The official said that 5.3.29 is the last version of 5.3. It makes me very sad that this problem appeared in the last version and has not been solved.
I searched online and found that no one had this problem. All the compilation and configuration processes are the same as before. The same upgrade script I wrote was used from 5.3.25 to 5.3.28. Logically speaking, with the same subversion series and the same compilation and configuration process, there should be no problems.
Why is there no problem from 5.3.25 to 5.3.28, but no problem after 5.3.29?
Today I finally found the root cause of the problem, and I was also drunk...
Since I don’t want to occupy additional ports, I have always used Unix socket between Nginx and PHP-FPM, and it is said that this method is more efficient.
After PHP was upgraded to 5.3.29, a 502 error occurred, and the error was reported as soon as the web page was opened. It was not like the Nginx prompt 502 caused by PHP execution timeout, but more like PHP-FPM terminated abnormally, or Ngxin Fastcgi is not connected at all.
Using PHP-FPM logs is also frustrating. I have clearly enabled the logs and set the log path, but still no logs are generated.
Okay, let’s find the problem based on the reasons inferred from the previous ideas:
1.PHP-FPM terminated abnormally as soon as it started working;
2.Ngxin is not connected to fastcgi at all.
The first possibility is eliminated directly, because when the 502 error occurs, the background PHP-FPM process does not exit and is still alive and well.
Then it is probably the second possibility. I modified the configuration files of Nginx and PHP-FPM and changed them to the traditional "address:port" format
In PHP-FPM configuration file:
Listen = 127.0.0.1:1234
In Nginx configuration file:
fastcgi_pass 127.0.0.1:1234
Restarting the service, the website opened successfully.
It seems that Nginx is not connected to PHP-FPM, so what is the problem? Did 5.3.29 remove the Unix socket connection method? I think it is unlikely. I checked the update log and did not see any relevant information. Project.
I changed the configuration files of Nginx and PHP-FPM back.
In PHP-FPM configuration file:
Listen = /tmp/php-cgi.sock
In Nginx configuration file:
fastcgi_pass unix:/tmp/php-cgi.sock;
Restart the service and get 502 again immediately.
First of all, I thought of checking the permissions. It was a test anyway, so I changed the permissions of the PHP-FPM sock file to 777 without saying anything.
chmod 777 /tmp/php-cgi.sock
Open the web page directly and it can be opened!
Okay, it’s a permissions issue. Restart the service and check the permissions of php-cgi.sock
-rwx------. 1 root root 663 September 18 00:16 php-cgi.sock
This. . . The reason is very clear. No wonder Nginx cannot connect to PHP-FPM. The permissions of php-cgi.sock are actually 700,
But here comes the question, why does the same compilation and configuration process work fine for versions before 5.3.28? I checked another server that has not been upgraded to 5.3.29:
srw-rw-rw- 1 root root 0 September 16 21:11 php-cgi.sock
I found that its permission is 666, which... I can’t understand... Why is the default permission configuration in 5.3.28 is 666, but in 5.3.29 it becomes 700?
Consult the PHP documentation to find the solution
Add the configuration file in PHP-FPM. The first two items are to specify the owner and user group of php-cgi.sock, and the last item is to specify the file permissions.
listen.owner = www
Listen.group = www
Listen.mode = 0666
Restart the service and the problem is solved.