Roger Gnanih
Introduction
Last night, I ran into a fairly critical problem on my VPS: all my sites were displaying an HTTP 500 error. The behavior was very strange:
- The page displayed a 500 error ("Connection timed out" on the Nginx side).
- After a refresh, the site worked again.
- A few minutes later, when clicking another link, the error came back.
At first, I thought the problem came from a specific Laravel project, but after checking, all the sites hosted on my VPS were affected. Here is how I analyzed this behavior and solved the real underlying problem.
1. The false leads (The right reflexes to have)
Faced with a 500 error on Laravel, the most frequent causes are generally incorrect permissions or a corrupted cache. Here are the classic steps I first followed:
Checking the PHP version and the Laravel Cache:
I checked my CLI version (php --ini), which was indeed PHP 8.3. I then cleared my application's cache to start from a clean base:
bash php artisan optimize:clear
Checking permissions:
I also reassigned the rights to the web user to make sure FPM could write to the folders:
bash chown -R www-data:www-data /var/www chmod -R 775 storage bootstrap/cache
Despite these steps and restarting the services, the 500 error kept coming back after about twenty minutes. Even stranger: the file storage/logs/laravel.log was completely empty. If Laravel wasn't logging anything, it meant the crash was happening before the application even ran.
2. The real culprit: The FPM system logs
Since the 500 error masked the real error and affected all the sites, we had to look deeper, at the PHP-FPM process manager level.
I ran this command to watch the system logs live:
bash tail -f /var/log/php8.3-fpm.log /var/log/nginx/error.log
Bingo! I saw this appear:
text WARNING: [pool www] child 8869 exited on signal 11 (SIGSEGV - core dumped) after 1492.295670 seconds from start
A SIGSEGV error (Signal 11 - Segmentation Fault). This means the PHP process (the "worker") tried to access corrupted memory and crashed hard. Nginx was therefore waiting for a response from a dead process, causing the 500 error, until FPM recreated a new worker (hence why it started working again after a "refresh").
On PHP 8.3, this "segfault" bug is often linked to memory leaks, the OPcache JIT compiler, or corruption of the operating system's time zone database.
3. The definitive solution
To fix this problem, you need to act on several fronts: force process recycling, disable the unstable OPcache feature, and repair the system library responsible for time zones.
Step 1: Force the recycling of PHP-FPM workers
By default, workers can run indefinitely. I modified the FPM pool configuration to kill them and recreate them cleanly every 500 requests.
bash sudo nano /etc/php/8.3/fpm/pool.d/www.conf
I uncommented and modified this line:
text pm.max_requests = 500
Step 2: Disable the OPcache JIT
To avoid memory compilation crashes, I disabled the JIT in the main configuration file.
bash sudo nano /etc/php/8.3/fpm/php.ini
I added:
text opcache.jit=disable
Step 3: Repair the time zone database (tzdata)
A very common case causing this type of unexplained 500 error is PHP's inability to read the system's time zone information (fatal error Timezone database is corrupt). To rule out this OS-related problem, it is strongly recommended to cleanly reinstall the package tzdata (on Debian/Ubuntu):
bash sudo apt-get install --reinstall tzdata
You will then see a prompt confirming your default timezone (e.g.: Africa/Porto-Novo). Then make sure you have the same value set in the date.timezone directive of your php.ini.
Step 4: Restart
All that was left was to apply all these configurations:
bash systemctl restart php8.3-fpm systemctl restart nginx
Conclusion
HTTP 500 errors on a VPS can be misleading. When all your applications crash at the same time, your Laravel logs are empty, and the site comes back to life after a simple F5, do not look in your PHP code.
The golden rule is to always check /var/log/phpX.X-fpm.log.
