Check the apache log and find that the mod_fcgid module is abnormal, prompting "Connection reset by peer:mod_fcgid:error reading data from FastCGI server", "Premature end of script headers:index.php", "process /usr/... apache/cgi-bin exit(communication error, get unexpected signal 7", to put it bluntly, PHP terminates execution early and exits without returning the header.
I searched online for a long time based on these errors, but never found any satisfactory results. The answer was even misled by people, thinking that it was a problem with the mod_fcgid module configuration.
Before I found a solution, I kept thinking that although php has been a bit slow recently, it can at least run, which means there is no problem with the configuration. ; Moreover, if phpinfo() is executed now, the program can still be executed. I sorted out the error pattern again and found that the mvc framework with too many includes will prompt 500 internal errors. What does this mean that php has been executed? The file cannot be included, why? The temporary file can only be moved when requesting these resources, and the temporary file has no extra space.
df -h
It turns out that this is the case.
Filesystem Size Used Avail Use% Mounted on /dev/sda1 6.8G 6.5G 17M 100% / ...
The system home directory / has exploded
So, search for large files
find / -type f -size +300M
found the php plug-in. Xdebug generates a lot of performance analysis files, and they are all recorded in 100M.
/tmp/profiler/cachegrind.out.1336 /tmp/profiler/cachegrind.out.1329 ....
So modify php.ini and store the analysis files elsewhere, or not save them at all
.# close xdebug profiler in php.ini xdebug.profiler_enable = off
Delete the xdebug performance analysis directory and php var tracking directory
rm -rf /tmp/profilter rm -rf /tmp/trace
Check the hard disk status again and find that 26% is used and 4.9G remains.
Filesystem Size Used Avail Use% Mounted on /dev/sda1 6.8G 1.7G 4.9M 26% / ...
You don’t even need to restart the httpd server, refresh the web, and it’s running normally again! !
To avoid future troubles, we need to install a scheduled cleaning software--tmpwatch. Set the timing time in the /etc/cron.daily/tmpwatch configuration
usr/sbin/tmpwatch "$flags" 30d /var/tmp
to 7d (must be in days)
usr/sbin/tmpwatch "$flags" 7d /var/tmp
Clean up regularly once a week.
For more related articles on the analysis and resolution of temporary file problems caused by Apache 500 errors, please pay attention to the PHP Chinese website!