PHP max_execution_time limits during blocking system calls

Answer

PHP’s max_execution_time does not provide a native way to count the time spent inside uninterruptible blocking system calls toward the limit. The timer measures wall‑clock time, but if the engine is inside a system call that does not accept signals (e.g., a raw stream read without a timeout, certain disk I/O, or some extension calls), the SIGPROF that enforces the limit is held pending and the script can exceed the configured seconds until the call returns.

Confirmed facts

• The limit is enforced by a setitimer that sends SIGPROF; when the signal is delivered PHP throws the fatal error "Maximum execution time of X seconds exceeded".
• Calls such as sleep(), usleep(), most database driver waits, and stream operations with a timeout are interruptible, so the limit is respected.
• If the blocking call is non‑interruptible, the signal stays pending and the script may run longer than max_execution_time until the call finishes or is interrupted externally.
• This behavior is the same across SAPIs (mod_php, PHP‑FPM, CLI) as long as the underlying timer uses real‑time signals; differences appear only if the SAPI disables signal handling.

Recommended steps for a strict wall‑clock timeout

1. Verify the current behavior – run a quick test:

ini_set('max_execution_time', '2');
sleep(5);
// Expect a fatal error after sleep returns, confirming wall‑clock counting.

2. Make blocking calls interruptible – wherever possible, use timeouts provided by the library or extension:
• For streams: stream_set_timeout($stream, $seconds);
• For database drivers: use the driver‑specific timeout option (e.g., PDO::ATTR_TIMEOUT, MySQLi mysqli_options($link, MYSQLI_OPT_CONNECT_TIMEOUT, $sec)).
• For cURL: set CURLOPT_TIMEOUT and CURLOPT_CONNECTTIMEOUT.
3. If you cannot make the call interruptible, enforce the timeout at a higher level:
• Web server: configure Apache’s Timeout directive or nginx’s proxy_read_timeout/fastcgi_read_timeout.
• PHP‑FPM: set request_terminate_timeout in the pool configuration.
• CLI: use pcntl_alarm (available only when pcntl is enabled) or launch a watchdog process that kills the script after a set period.
4. When pcntl is not available (typical web SAPI) – rely on the server‑level timeout described above; there is no pure‑PHP user‑land method that can interrupt a blocking system call.

Missing diagnostic detail

To refine the recommendation, please confirm which SAPI and operating system you are running (e.g., Apache/mod_php on Linux, nginx+PHP‑FPM, or Windows IIS). This determines whether server‑level timeout directives are applicable or if a pcntl‑based watchdog is feasible.