PHP Maximum Execution Time Exceeded on CentOS Stream / Rocky Linux: Troubleshooting & Resolution

Resolve the 'PHP maximum execution time of 30 seconds exceeded' error on CentOS Stream and Rocky Linux. Learn to diagnose, adjust PHP, FPM, and web server timeouts for optimal performance.

Resolve the 'PHP maximum execution time of 30 seconds exceeded' error on CentOS Stream and Rocky Linux. Learn to diagnose, adjust PHP, FPM, and web server timeouts for optimal performance.

When a PHP application attempts to perform a task that takes longer than the default allotted time, you'll encounter the "PHP maximum execution time exceeded" error. This guide provides a highly technical, step-by-step approach to diagnose and resolve this common timeout issue on CentOS Stream and Rocky Linux environments, ensuring your web applications run smoothly.

Symptom & Error Signature

Users might experience a blank page, a "500 Internal Server Error" message, or a partial page load. The definitive symptom, however, is found in your server's log files.

Typical error messages you'll observe in your PHP-FPM, Nginx, or Apache error logs:

PHP-FPM Log (e.g., /var/log/php-fpm/www-error.log or systemctl status php-fpm):

[28-Jul-2026 10:30:45 UTC] WARNING: [pool www] child 1234, script '/var/www/html/index.php' (request: "GET /index.php") execution timed out (30.123 sec), terminating
[28-Jul-2026 10:30:45 UTC] WARNING: [pool www] `max_execution_time` for script '/var/www/html/index.php' has been exceeded, terminating
[28-Jul-2026 10:30:45 UTC] WARNING: [pool www] `request_terminate_timeout` (`30s`) for script '/var/www/html/index.php' has been exceeded, terminating
[28-Jul-2026 10:30:45 UTC] ERROR: child 1234 exited on signal 9 (SIGKILL) after 30.123 seconds from start

Nginx Error Log (e.g., /var/log/nginx/error.log):

2026/07/28 10:30:45 [error] 4567#4567: *8976 fastcgi upstream timed out (110: Connection timed out) while reading response header from upstream, client: 192.168.1.1, server: example.com, request: "GET /index.php", upstream: "fastcgi://unix:/run/php-fpm/www.sock", host: "example.com"

Apache HTTPD Error Log (e.g., /etc/httpd/logs/error_log):

[Tue Jul 28 10:30:45.123456 2026] [proxy_fcgi:error] [pid 7890:tid 123456789012345] (70007)The timeout specified has expired: [client 192.168.1.1:54321] AH01075: Error dispatching request to : from 127.0.0.1:9000 (polling), referer: http://example.com/

Root Cause Analysis

The "maximum execution time exceeded" error occurs when a PHP script runs for longer than the configured timeout limit. Several factors can contribute to this:

Default PHP max_execution_time: By default, PHP's max_execution_time is often set to 30 seconds. This is usually sufficient for most web pages but can be too short for complex tasks like data imports, image processing, report generation, or lengthy API calls.
Inefficient PHP Code: Poorly optimized code, inefficient database queries without proper indexing, long-running loops, or recursive functions without proper termination conditions can lead to scripts exceeding the time limit.
External Dependencies: Slow responses from external APIs, third-party services, or remote database servers can cause a script to wait indefinitely (or until timeout) for a response.
Resource Constraints: While less direct, a server heavily burdened by CPU, RAM, or I/O operations can slow down PHP script execution significantly, causing even moderately complex scripts to hit the timeout wall.
PHP-FPM request_terminate_timeout: When using PHP-FPM, there's an additional timeout (request_terminate_timeout) in the FPM pool configuration that can override or work in conjunction with max_execution_time. If this is lower, it will terminate the script regardless of the php.ini setting.
Web Server Timeouts: Both Nginx (fastcgi_read_timeout, proxy_read_timeout) and Apache (ProxyTimeout, Timeout) have their own timeout configurations. If these are set lower than PHP's execution time, the web server might terminate the connection before PHP can finish its process, resulting in an upstream timeout error.

Step-by-Step Resolution

To resolve this issue, you'll need to adjust timeouts across PHP, PHP-FPM, and your web server configuration.

1. Identify the Culprit Script and Review Logs

Before increasing timeouts, always try to pinpoint which script is causing the issue. Your logs often provide this information.

# For PHP-FPM logs (CentOS/Rocky Linux usually ships PHP-FPM configs in /etc/php-fpm.d/)
sudo tail -f /var/log/php-fpm/www-error.log | grep "execution timed out"

# For Nginx errors
sudo tail -f /var/log/nginx/error.log | grep "upstream timed out"

# For Apache errors
sudo tail -f /etc/httpd/logs/error_log | grep "timeout specified has expired"

Use grep -C 5 to see 5 lines before and after the matched entry for more context.

2. Increase `max_execution_time` in `php.ini`

This is the primary PHP setting for execution time.

Locate php.ini: PHP often uses different php.ini files for CLI and FPM/Web SAPI. For web requests managed by PHP-FPM, you typically need to modify the php.ini associated with PHP-FPM. To find the correct php.ini file:
```
php -i | grep "Loaded Configuration File"
# Example output: Loaded Configuration File => /etc/php.ini
```
The path is commonly /etc/php.ini on CentOS/Rocky Linux.
Edit php.ini: Open the file using a text editor like vi or nano.
```
sudo vi /etc/php.ini
```
Find and modify max_execution_time:
```
; Maximum execution time of each script, in seconds
; http://php.net/max-execution-time
max_execution_time = 300 ; Change 30 to a higher value, e.g., 300 seconds (5 minutes)
```
While increasing this value can solve the immediate timeout, setting it excessively high (e.g., 0 for unlimited) is generally not recommended as it can mask deeper code issues and allow runaway scripts to consume all server resources, potentially leading to DoS.
Restart PHP-FPM: After modifying php.ini, you must restart the PHP-FPM service for changes to take effect.
```
sudo systemctl restart php-fpm
```

3. Adjust `request_terminate_timeout` in PHP-FPM Pool Configuration

PHP-FPM has its own timeout setting per pool which can override or interact with max_execution_time.

Locate PHP-FPM pool configuration: The default pool configuration is typically found at /etc/php-fpm.d/www.conf.
```
sudo vi /etc/php-fpm.d/www.conf
```

Find and modify request_terminate_timeout:

; The timeout for serving a single request after which the worker process will
; be killed. This option should be used when the 'max_execution_time' PHP
; configuration option does not work for some reason, for example when a
; signature was not present in the PHP configuration file.
; Setting this value to 0 means 'off'.
; Available units: s(econds)(default), m(inutes), h(ours), or d(ays)
request_terminate_timeout = 300s ; Set to a value greater than or equal to max_execution_time

Ensure request_terminate_timeout is set to a value equal to or greater than max_execution_time. If request_terminate_timeout is lower, PHP-FPM will kill the process regardless of max_execution_time.

Restart PHP-FPM:
```
sudo systemctl restart php-fpm
```

4. Configure Web Server Timeouts (Nginx or Apache HTTPD)

Your web server also needs to be configured to wait long enough for PHP-FPM to finish.

For Nginx (using `fastcgi_pass`)

Edit Nginx configuration: This is typically in your site's server block, e.g., /etc/nginx/conf.d/your_site.conf or /etc/nginx/nginx.conf.
```
sudo vi /etc/nginx/conf.d/your_site.conf
```

Add or modify fastcgi_read_timeout: Inside the location ~ .php$ block:

location ~ .php$ {
    fastcgi_pass   unix:/run/php-fpm/www.sock; # Or your specific FPM socket/port
    fastcgi_index  index.php;
    fastcgi_param  SCRIPT_FILENAME $document_root$fastcgi_script_name;
    include        fastcgi_params;

    # Set fastcgi read timeout to match or exceed PHP-FPM's request_terminate_timeout
    fastcgi_read_timeout 300s; # e.g., 300 seconds (5 minutes)
}

If you're using Nginx as a reverse proxy to another web server (e.g., Apache), you might need to adjust proxy_read_timeout instead of fastcgi_read_timeout.

Test Nginx configuration and reload:

sudo nginx -t
sudo systemctl reload nginx

For Apache HTTPD (using `mod_proxy_fcgi` or `mod_php`)

Edit Apache configuration: This is commonly in /etc/httpd/conf/httpd.conf or a virtual host file in /etc/httpd/conf.d/.
```
sudo vi /etc/httpd/conf.d/your_site.conf
```
Set ProxyTimeout and/or Timeout:
- ProxyTimeout: If using mod_proxy_fcgi to connect to PHP-FPM.
- Timeout: The general request timeout for Apache.
- Make sure mod_proxy and mod_proxy_fcgi modules are loaded (uncomment LoadModule proxy_module modules/mod_proxy.so and LoadModule proxy_fcgi_module modules/mod_proxy_fcgi.so in httpd.conf if not).
```
<VirtualHost *:80>
    ServerName example.com
    DocumentRoot /var/www/html

    # If using mod_proxy_fcgi to connect to PHP-FPM
    <FilesMatch .php$>
        SetHandler "proxy:fcgi://127.0.0.1:9000" # Or your PHP-FPM socket
    </FilesMatch>

    # Set ProxyTimeout (for mod_proxy_fcgi)
    ProxyTimeout 300

    # General Apache request timeout (also important)
    Timeout 300

    # ... other configurations
</VirtualHost>
```
If you are using mod_php (PHP as an Apache module, less common with modern FPM setups but still possible), the max_execution_time in php.ini will be sufficient, and ProxyTimeout is not relevant. You might still need to adjust Apache's Timeout directive.

Test Apache configuration and reload:

sudo apachectl configtest
sudo systemctl reload httpd

5. Optimize PHP Code and Application Logic

Increasing timeouts is a workaround; the best long-term solution is to optimize your code.

Review and Refactor: Identify the exact function or loop that's taking too long. Can the logic be improved? Are there redundant operations?
Database Optimization:
- Ensure all relevant columns are indexed.
- Refine SQL queries to be more efficient (e.g., avoid SELECT *, use JOINs efficiently).
- Use caching for frequently accessed data (e.g., Redis, Memcached).
Caching: Implement application-level caching for expensive computations or API responses.
Asynchronous Processing: For very long-running tasks (e.g., bulk data processing, sending many emails), consider offloading them to a background job queue (e.g., Redis Queue, RabbitMQ, Laravel Queues) where they can run independently without holding up web requests.
Resource Management: Ensure external API calls have reasonable timeouts themselves and handle failures gracefully.

6. Increase Server Resources

If code optimization is not enough, or if the task is inherently resource-intensive, consider:

Vertical Scaling: Upgrade CPU, RAM, or switch to faster storage (SSD/NVMe).
Horizontal Scaling: Distribute load across multiple servers using a load balancer.

7. Monitor and Debug

After applying changes, monitor your application and server logs closely. Tools like strace can help debug specific processes, and application performance monitoring (APM) tools (e.g., New Relic, Datadog, Blackfire) can provide deep insights into script execution times and bottlenecks. Xdebug is an invaluable tool for profiling PHP code locally.

By systematically adjusting these configuration parameters and focusing on code optimization, you can effectively resolve the "PHP maximum execution time exceeded" error and ensure the stability and performance of your web applications on CentOS Stream and Rocky Linux.