RequestHandlerRunner graceful shutdown limits under PHP‑FPM

Short answer

Under PHP‑FPM, RequestHandlerRunner's graceful shutdown effectively does nothing useful. Its signal handling is designed for long‑running SAPIs (RoadRunner, Swoole, ReactPHP, PHP‑CLI loops) where one process serves many requests. Under FPM each worker handles a single request and exits, so there is no request loop to stop and no "finish current request, refuse new ones" phase for the runner to manage. Treat shutdown under FPM as an infrastructure concern, not a laminas concern.

Confirmed behavior vs. likely explanation

Confirmed by design: the runner's graceful shutdown is opt‑in and requires pcntl. It registers handlers (typically SIGTERM/SIGINT) that set a flag the request loop checks between iterations. No loop, no benefit.

Likely, but verify on your stack: when FPM's master sends SIGTERM to a worker (reload, request_terminate_timeout, process_control_timeout expiry), whether your registered handler runs before exit depends on FPM version and pool settings. Do not rely on laminas handlers as an interception point here; assume the request is simply killed.

Answers to the open questions

1. SIGTERM mid‑request under FPM: not reliably intercepted. FPM's master owns the worker lifecycle. Verify with a test: log inside a register_shutdown_function and a custom pcntl_signal handler, then send SIGTERM to a busy worker.
2. Disconnect detection without output: no. connection_aborted() only reflects the abort after PHP attempts output (or the SAPI notices it). With default ignore_user_abort(false), PHP terminates the script on disconnect once a write occurs. There is no poll‑only mechanism.
3. Shutdown timeout for in‑flight middleware: laminas provides none. In long‑running mode the runner stops accepting new requests and finishes the current one; any hard deadline comes from the surrounding server (RoadRunner/Swoole config) or PHP's max_execution_time.

What to do in this case

• Under FPM, control shutdown via php-fpm.conf: process_control_timeout, request_terminate_timeout, plus web server timeouts and max_execution_time.
• Inspect your installed vendor/laminas/laminas-httphandlerrunner source to confirm which signals your version registers — this is version‑sensitive.
• If you need cooperative cancellation (e.g., aborting a slow DB call), implement it yourself: a shared flag set by a signal handler in long‑running mode, checked in middleware. Laminas ships no cancellation token or request context.

One diagnostic that would change this recommendation: confirm whether pcntl is even enabled in your FPM build (php -m | grep pcntl). If it is absent, the runner's graceful shutdown path is dead code in your deployment regardless of SAPI.