Persistent PHP-FPM Socket Errors Impacting Website Performance After cPanel Server Optimization

• Verify PHP-FPM Service Stability & Socket Creation: This is crucial. Even if FPM *seems* to be running, individual user pools might be crashing or failing to start.
  • Check the status of the specific PHP-FPM service for the affected user: systemctl status [email protected] (replace XX with PHP version, username with cPanel user).
  • Review its journal logs for any startup errors or crashes: journalctl -u [email protected] -f. Look for anything indicating failure to bind to the socket or exit codes.
  • Confirm the socket file exists when the service is supposedly running: ls -l /run/php-fpm/username.sock (adjust path if different). If it's missing, the service isn't properly initializing or is crashing immediately.
• SELinux Policies: This is a very strong candidate for "No such file or directory" errors, especially on AlmaLinux 8. SELinux can block processes (like Nginx or PHP-FPM) from creating or accessing files in certain contexts.
  • Check for recent SELinux denials: grep "php-fpm" /var/log/audit/audit.log | audit2allow -M myphpfpm then review myphpfpm.te. Or simply setenforce 0 temporarily to see if the issue disappears (do not leave it off in production, but it helps diagnose).
  • Ensure the correct SELinux context is applied to the socket directory and files: semanage fcontext -a -t httpd_var_run_t "/run/php-fpm(/.*)?" and then restorecon -Rv /run/php-fpm.
• File Permissions & Ownership: Double-check the permissions on the `/run/php-fpm/` directory and the actual socket files. Nginx typically runs as user `nginx` or `apache`, and needs read/write access to connect to the socket.
  • Ensure the parent directory `/run/php-fpm/` has appropriate permissions (e.g., 755 or 770) and ownership that allows PHP-FPM to create the socket and Nginx to access it.
  • The socket file itself should usually be owned by the cPanel user and group, with permissions like 660.
• Nginx & PHP-FPM Socket Path Mismatch: While you likely checked this, confirm that the `upstream` path in your Nginx configuration (e.g., in /etc/nginx/conf.d/example.com.conf) precisely matches the `listen` directive in the relevant PHP-FPM pool configuration file (e.g., /etc/php-fpm.d/username.conf or cPanel's equivalent). A single character mismatch can cause this.
• Kernel-Level Socket Limits & File Descriptors: Although less likely for a "No such file" error, if PHP-FPM itself is running out of file descriptors, it might fail to create the socket.
  • Check the `ulimit -n` for the PHP-FPM process (you might need to find its PID and then check `cat /proc/PID/limits`).
  • Review system-wide file descriptor limits: sysctl fs.file-max.
• EasyApache 4 Module Conflicts / PHP-FPM Configuration Reloads: Sometimes, certain EasyApache modules or custom configurations can interfere with how PHP-FPM reloads or handles its socket. Ensure Nginx and PHP-FPM services are restarted in the correct order after any changes, or consider if a specific EA4 module is causing instability.

Emma, that call-out about the socket file not even being there or the SELinux policies was spot on! I was so caught up checking resource limits, but verifying the socket's actual presence with ls -l and then diving into SELinux logs quickly identified the blockage.