Upgrading PHP from 5.3.28 to 5.3.29 today, found website It cannot be opened, and it prompts "502 bad gateway". You can access static resources, 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 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 is one of the best versions for compatibility. One, of course 5.2 is also available.
I really can't stand my obsessive-compulsive disorder. The official said that 5.3.29 is the last version of 5.3. It makes me 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. From 5.3.25 to 5.3.28, I used the same upgrade script I wrote. The logic is the same. Sub-version series, 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 sockets 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 Nginx prompting 502 due to PHP execution timeout, but more like PHP-FPM terminated abnormally, or Ngxin was not connected at all. On fastcgi.
The logs using PHP-FPM are 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
After 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's unlikely. I checked the update log and didn't see any related projects.
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 I thought of checking the permissions. It was a test anyway, so I changed the permissions of the sock file of PHP-FPM 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 it becomes 700 in 5.3.29?
Check 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.
![[Web front-end] Node.js quick start](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
