PHP-FPM worker exit rate: normal recycling vs abnormal deaths

PHP-FPM workers exit constantly in a healthy pool. pm.max_requests exists precisely to make workers exit on purpose after serving a fixed number of requests. The master forks a replacement, and the pool continues serving traffic. An exit rate of zero over hours means pm.max_requests is set to 0 (unlimited), which means workers never recycle and any memory leak accumulates without bound.

The question is never “are workers exiting?” but “why are workers exiting?” The master writes a line for every child termination with enough detail to classify it as normal recycling or an abnormal death. Only two specific signals feed into emergency_restart_threshold, so the wrong exit pattern can mean anything from a harmless extension quirk to a crash loop that pages you at 3 a.m.

What the worker exit stream tells you

Every time a child terminates, the master reaps it (via SIGCHLD) and writes a line to the PHP-FPM error log. The line contains the pool name, child PID, exit mechanism, signal or exit code, and how long the child lived from spawn to death.

Two fields do the diagnostic work.

The exit mechanism. “exited with code N” means the worker called exit() itself or returned from the request handler and shut down normally. “exited on signal N” means something killed it from outside: the kernel (OOM), the master (request_terminate_timeout), or a hardware-level fault (segfault).

The signal or code number. Code 0 is the only healthy exit. Any non-zero code or any signal is abnormal, though some are more urgent than others.

The rate is the third axis. A single SIGSEGV per day on a pool serving millions of requests is noise. Three SIGSEGVs in five minutes with falling throughput is a crash loop. The absolute count is meaningless without the time window and traffic context.

flowchart TD
    A["Worker exit logged"] --> B{"Exit code 0?"}
    B -->|"Yes + max_requests set"| C["Healthy recycling"]
    B -->|"No, or max_requests = 0"| D["Abnormal"]
    D --> E{"Which signal or code?"}
    E -->|"11 SIGSEGV, 7 SIGBUS"| F["Extension bug or corruption"]
    E -->|"9 SIGKILL"| G["OOM or external kill"]
    E -->|"15 SIGTERM"| H["request_terminate_timeout"]
    E -->|"127, 126"| I["Missing lib or permission"]

How PHP-FPM reaps and logs exits

The master sits in an event loop. When a child dies, the kernel delivers SIGCHLD, the master calls wait() to reap the corpse and read the exit status. The status is either a clean exit code (WIFEXITED) or a signal number (WIFSIGNALED). The master logs the result, decrements the live child count, and forks a replacement.

Normal exit (code 0):

NOTICE: [pool www] child 12345 exited with code 0 after 312.456789 seconds from start

Signal death:

WARNING: [pool www] child 12345 exited on signal 11 (SIGSEGV) after 2.103456 seconds from start

The key differences: “code” versus “signal”, the exit status number, and the log level. Normal code-0 exits appear at NOTICE level. Signal deaths appear at WARNING level.

The “after N seconds from start” field is useful for triage. A worker that lived 300 seconds and exited with code 0 probably hit pm.max_requests and recycled. A worker that lived 2 seconds and exited on signal 11 crashed almost immediately after being forked. That short lifetime is a classic crash-loop signature.

Normal recycling: what healthy exits look like

When pm.max_requests is set to a positive integer (500 and 1000 are common defaults), each worker tracks how many requests it has served. When the counter reaches the limit, the worker finishes its current request, delivers the response, and calls exit(0). There is no mid-request interruption. The master forks a replacement, and the pool is back at full strength within milliseconds.

This is the designed mechanism for bounding memory growth. Without it, workers run forever, and any per-request memory leak in application code, extensions, or the PHP runtime accumulates without bound.

Recognizing healthy recycling:

• Exit code 0. Always. A code-0 exit after a non-trivial number of requests served is recycling, not a crash.
• NOTICE log level. These do not belong in your alert stream.
• Predictable interval. With pm.max_requests = 500 and roughly 10 requests/second per worker, each worker lives about 50 seconds. The exit rate is steady, not bursty.
• No signal number. The log says “exited with code 0”, never “exited on signal”.
• Total process count stable. The master spawns a replacement immediately, so total processes should not dip.

If you see code-0 exits at a rate consistent with your traffic and pm.max_requests setting, do nothing.

Abnormal deaths: the signal and exit code catalog

Any exit that is not a code-0 recycling event is abnormal. The category ranges from “investigate when convenient” to “page right now.”

Two things to note about this catalog.

First, only SIGSEGV (11) and SIGBUS (7) feed into emergency_restart_threshold . Signal 9 (OOM kills) does not. SIGTERM from request_terminate_timeout does not. If your workers are being OOM-killed in a loop, the master will respawn them forever without ever triggering an emergency restart. This is a common surprise.

Second, signal 9 is not always the OOM killer. On systemd-managed hosts, the watchdog, an admin script, or a cgroup memory limit can all deliver SIGKILL. Check dmesg for “Out of memory” or “Killed process” lines to confirm the source before blaming PHP memory usage.

Reading the exit rate in context

An exit is a data point. The rate is the signal. Three time windows matter.

Steady, predictable code-0 exits. Normal recycling. The rate should be roughly throughput / pm.max_requests exits per second across the pool. If you serve 500 requests/second and pm.max_requests is 500, you should see roughly 1 exit per second.

Sporadic signal deaths (a few per day). Usually an extension quirk or a rare code path that triggers a segfault. Investigate during business hours. Capture a core dump if the rate is high enough to reproduce.

Burst of signal deaths (multiple within minutes). This is the crash-loop pattern. The master forks a worker, the worker crashes almost immediately (“after 2 seconds from start”), the master forks another, it crashes again. The pool never reaches its configured worker count. If the rate exceeds emergency_restart_threshold within emergency_restart_interval, the master execvp()s itself. That is a full pool restart with a brief total outage.

Severity guidance:

• PAGE: 3 or more SIGSEGV/SIGBUS exits within 5 minutes, combined with falling throughput or web-server 502 errors.
• TICKET: Elevated abnormal exit rate without confirmed user impact. Investigate before it escalates.
• INFO: Periodic code-0 exits at intervals consistent with pm.max_requests. No action needed.

Configuring the safety nets

Two configuration areas determine how the master responds to abnormal deaths.

emergency_restart_threshold and emergency_restart_interval (in php-fpm.conf, not per-pool):

• Both default to 0, which disables the feature entirely.
• When set (e.g., emergency_restart_threshold = 10, emergency_restart_interval = 60), the master counts SIGSEGV/SIGBUS deaths within the interval . If the count reaches the threshold, the master restarts all pools via execvp().
• This is a circuit breaker, not a fix. It prevents a crash loop from running forever, but it causes a brief total outage during the restart.
• Only SIGSEGV and SIGBUS count toward the threshold . OOM kills, SIGTERM, and non-zero exit codes do not trigger it.

rlimit_core (per-pool):

• Defaults to 0, which disables core dumps.
• Set to unlimited to capture core files when workers segfault. The core file contains the exact crash stack trace.
• On PHP 7.0.29+, 7.1.17+, and 7.2.5+, you also need process.dumpable = yes in the pool config if the master and pool run as different users . Without it, the kernel may refuse to write the core file even with rlimit_core set.

Reference commands for inspecting the exit stream

These commands narrow the cause when you see a burst of abnormal exits. All are read-only.

# Count all child exits in the last hour
journalctl -u php-fpm --since "1 hour ago" | grep -c "exited"

# Isolate signal deaths (segfaults and bus errors)
grep -c "SIGSEGV\|SIGBUS" /var/log/php-fpm/error.log

# Check the kernel log for OOM kills targeting php-fpm
dmesg | grep -i "oom.*php\|killed process"

# Check if emergency_restart has fired recently
grep "failed processes threshold\|initiating reload" /var/log/php-fpm/error.log

# Confirm whether pm.max_requests is set (0 = unlimited = no recycling)
php-fpm -tt 2>&1 | grep max_requests

The dmesg output often has more detail about segfaults than the PHP-FPM log itself, including the faulting address and the shared library involved. If you have core dumps enabled, coredumpctl (on systemd systems) or the configured core dump path will give you the full backtrace.

Signals to watch in production

How Netdata helps

• Per-second polling of the PHP-FPM status page surfaces exit-rate changes within the window where a crash loop is still recoverable.
• Correlation between worker exits and throughput shows whether abnormal exits are actually impacting users (falling accepted connections rate) or are background noise (throughput stable).
• Memory metrics alongside exit logs distinguish signal-9 OOM kills (RSS climbing toward the limit) from extension segfaults (RSS stable, signal 11).
• Anomaly detection on the exit rate flags a burst of signal deaths even when no static threshold has been crossed.
• cgroup-level memory tracking in containerized deployments catches OOM kills that PHP-FPM cannot see in its own logs.

Related guides

• PHP-FPM 504 Gateway Timeout: requests accepted but never finishing in time
• PHP-FPM active processes near max_children: reading pool utilization
• PHP-FPM in containers: cgroup limits and the silent OOM kill
• How PHP-FPM actually works in production: a mental model for operators
• PHP-FPM idle processes at zero: no burst headroom left
• PHP-FPM listen queue growing: the earliest signal of saturation
• PHP-FPM “server reached pm.max_children setting (N), consider raising it”
• PHP-FPM pm.max_requests: worker recycling as the memory-leak safety net
• PHP-FPM memory leak: per-worker RSS climbing until the box runs out
• PHP-FPM memory_limit vs worker RSS: why workers exceed the limit you set
• PHP-FPM monitoring checklist: the signals every production pool needs
• PHP-FPM monitoring maturity model: from survival to expert