Back to Changelog
v1.0.237
Critical fix for orphan PHP-FPM listening socket causing 503 errors despite service appearing active
New Feature
1- Layer 3: new independent PHP-FPM socket health watcher (phpfpm_socket_watcher.go) runs every 60 seconds on all installations regardless of resource isolation setting, automatically detects orphan sockets and triggers recovery within 60 seconds maximum
Improvements
2- End-to-end tested: bug reproduced exactly (socket deleted while master alive, HTTP 503 confirmed), watcher detected orphan at 70s mark, restarted the service automatically, HTTP 200 restored — equivalent to cPanel phpfpm-monit and Plesk psa-php-fpm-watchdog
- Maximum observable downtime reduced from unbounded (permanent until manual intervention) to at most 60 seconds for any future orphan socket scenario
Bug Fixes
3- Critical: per-user PHP-FPM services could enter an orphan socket state where the master process held a listening socket fd but the filesystem socket file was unlinked, causing Apache/nginx to return 503 for all requests while the service appeared active (root cause of ZothNET phildo.xyz 4-hour downtime incident)
- Layer 1: increased TimeoutStopSec from 3s to 15s in all 12 per-user PHP-FPM unit templates (PHP 5.6 through 9.0), reducing the race window by 5x during service stop operations
- Layer 2: ExecStopPost now performs a defensive PID check before unlinking the socket file — if the PHP-FPM master process is still alive the socket is left intact, completely closing the race condition between SIGTERM delivery and socket unlink