To locate the error log directory for each PHP script running under PHP-FPM, inspect the error_log directive within the specific pool configuration file located in /etc/php-fpm.d/ or /etc/php/*/fpm/pool.d/. The path defined there is where all errors for that particular pool are written. You can also verify the active configuration using the php-fpm -t command to ensure the settings are valid before restarting the service.
Understanding PHP-FPM Pool Configuration
PHP-FPM (FastCGI Process Manager) operates by managing multiple pools of worker processes. Each pool is designed to handle requests from a specific virtual host, domain, or application context. This architecture allows administrators to isolate resources and logging for different parts of a web server. For instance, a production site might run in one pool while a staging environment runs in another, each with its own distinct error handling policies.
The configuration for these pools is stored in individual files, typically named after the pool itself, such as www.conf, blog.conf, or api.conf. These files reside in system-specific directories depending on your Linux distribution or macOS setup. On Debian-based systems like Ubuntu, you will often find them in /etc/php/8.1/fpm/pool.d/. On Red Hat-based systems like CentOS or Fedora, they are commonly located in /etc/php-fpm.d/. Understanding this structure is the first step in diagnosing where logs are being sent.
Locating the Configuration Files
To begin troubleshooting, you need to identify which configuration file corresponds to the PHP script causing issues. If you are unsure which pool is handling a specific request, check your web server configuration (Nginx or Apache). In Nginx, look for the fastcgi_pass directive pointing to a Unix socket or TCP address. This address usually matches the listen directive in one of the PHP-FPM pool configuration files.
Once you have identified the relevant pool file, open it with a text editor. Look for the line that begins with error_log. This directive explicitly defines the absolute path to the file where PHP-FPM will write error messages. If this line is commented out or missing, PHP-FPM may default to syslog or a standard location depending on the global configuration, but specifying it explicitly is best practice for clarity.
Interpreting the Error Log Path
The value assigned to the error_log directive is not necessarily a directory; it is a full file path. For example, a setting might look like error_log = /var/log/php-fpm/myapp-error.log. In this case, the "directory" is /var/log/php-fpm/, and the specific log file is myapp-error.log. It is crucial to understand that PHP-FPM does not automatically create subdirectories if they do not exist. Therefore, the parent directory must already be present and writable by the user running the PHP-FPM process.
If you are managing multiple domains, each domain should ideally have its own pool configuration file with a unique error_log path. This separation prevents log files from becoming unmanageably large and makes it easier to filter errors specific to one application. When debugging, always check the file specified in the pool config rather than assuming a global log location.
Verifying Permissions and Ownership
Even if the correct path is defined, PHP-FPM will fail to write to the log file if permissions are incorrect. The directory containing the log file must be owned by the user that PHP-FPM runs as, which is typically defined by the user and group directives in the same configuration file. Common users include www-data, apache, or nobody.
To fix permission issues, you can change the ownership of the log directory using the chown command. For example:
sudo chown www-data:www-data /var/log/php-fpm/
sudo chmod 755 /var/log/php-fpm/After adjusting permissions, restart the PHP-FPM service to apply changes. On systemd-based systems, use sudo systemctl restart php-fpm or sudo systemctl restart php8.1-fpm. Always verify that the service started successfully without errors, as syntax mistakes in the configuration file can prevent the service from starting at all.
Testing and Debugging
Once the configuration is set and permissions are corrected, test the setup by triggering an error in your PHP script. A simple way to do this is to introduce a deliberate syntax error or call a non-existent function. Then, check the specified log file using the tail command:
tail -f /var/log/php-fpm/myapp-error.logThis real-time view allows you to see if errors are being captured correctly. If the log file remains empty despite errors occurring, double-check the error_log path in the pool configuration and ensure that the web server is indeed proxying requests to that specific pool. Misconfigurations in Nginx or Apache upstream definitions are a common cause of logs appearing in the wrong place.
For more advanced diagnostics, you can use the php-fpm -t command to test the syntax of your configuration files. This command returns a success message if the configuration is valid, or lists specific errors if there are typos or invalid directives. It is a quick sanity check before restarting the service.
Managing Logs Across Environments
In development environments, it is often helpful to set error_log = /dev/stderr so that logs appear in the terminal output when running PHP-FPM manually. This can speed up debugging significantly. However, in production, writing to a dedicated file is preferred for persistence and integration with log rotation tools.
Log rotation is essential to prevent disk space exhaustion. Configure logrotate to handle the specific log files defined in your PHP-FPM pools. Ensure that the rotation strategy includes compressing old logs and removing very old entries to maintain system health. Properly managed logs provide a clear audit trail and aid in rapid incident response.
Frequently Asked Questions
Where is the global PHP-FPM error log located?
The global error log is typically defined in the main php-fpm.conf file, not in the pool-specific configurations. Its path is controlled by the error_log directive at the top level of that file. This log captures startup errors and critical failures that occur before or outside of specific pool contexts.
Why are my PHP errors not showing up in the FPM log?
If errors are missing, check the php.ini settings for display_errors and log_errors. While log_errors controls whether errors are logged, display_errors controls their visibility on the screen. Additionally, ensure that the error_reporting level includes the types of errors you are trying to capture, as some levels may be suppressed by default.
Can I use syslog instead of a file for PHP-FPM logs?
Yes, you can set error_log = syslog in the pool configuration. This sends error messages to the system logger, which then writes them to standard syslog locations like /var/log/syslog or /var/log/messages. This approach integrates well with centralized logging systems but may require additional filtering to separate PHP errors from other system events.
How do I rotate logs for multiple PHP-FPM pools?
Create separate logrotate configuration files for each pool's log file. Define the path, rotation frequency, and compression settings in each file. This ensures that logs for different applications are managed independently, preventing one noisy application from affecting the log retention policies of others.
What happens if the log directory does not exist?
PHP-FPM will fail to start or will refuse to write logs if the specified directory does not exist or lacks write permissions. The service will likely report an error during startup or in the global error log. Always ensure that the directory exists and has the correct ownership before defining the path in the pool configuration.