PHP-FPM emergency restart: "failed processes threshold reached, initiating reload"

You see a NOTICE line in the PHP-FPM error log:

NOTICE: failed processes threshold (N in M sec) is reached, initiating reload

The master has watched enough children die from SIGSEGV or SIGBUS inside a configured interval and is giving up on soft recovery. It is about to execvp() itself: every pool is recycled, the OPcache shared memory segment is destroyed, and for a few seconds no PHP request can be served. When traffic returns, every worker pays a compilation penalty while the cache warms.

This is not “server reached pm.max_children” and it is not a graceful SIGUSR2 reload. It is the FPM circuit breaker, and by default it is disabled (emergency_restart_threshold = 0). If you are seeing the message, someone set the threshold to a non-zero value at some point. If you expected the master to self-heal and it never did: with the default of 0 the breaker never trips and a crash loop runs degraded for as long as the master keeps respawning workers.

A single event can self-heal: the restart clears whatever transient state caused the segfaults and the pool comes back. Repeated events are a different problem. There is a persistent bug, the breaker is now part of a crash loop, and every restart wipes OPcache again.

What this means

The mechanism is narrow and easy to misread:

• The master counts only child exits from SIGSEGV (signal 11) and SIGBUS (signal 7). Those are the only signals that increment the counter.
• Exits from SIGKILL (signal 9, the OOM killer), SIGTERM, SIGABRT (signal 6), or any non-zero exit code do not count toward the threshold. A worker storm killed by the OOM killer will not trip the breaker on its own.
• If the running count inside emergency_restart_interval reaches emergency_restart_threshold, the master execvp()s itself, restarting every pool in the configuration, not just the affected one.
• The interval defines the window. The official documentation does not specify exactly when the count resets if the threshold is not reached.
• During the restart there is a brief window where the master has replaced itself and no workers are ready. New connections can land on the listen socket, but workers cannot accept them until they are forked.

Side effects that compound the original outage:

• OPcache is wiped, because the shared memory segment owned by the old master is destroyed. Every script is recompiled on first hit. On a large codebase that is seconds to minutes of elevated CPU and latency.
• Status page counters (accepted conn, max children reached, max active processes) reset to zero, which hides the original signal from monitoring that does not keep history.
• If the same request pattern recurs when the new pool starts (client retry, popular endpoint), the new worker may hit the same code path immediately and segfault again, producing a tight restart loop.

flowchart TD
  A["Worker exits"] --> B{"Signal?"}
  B -->|SIGSEGV / SIGBUS| C["Increment crash counter"]
  B -->|SIGKILL / SIGTERM / SIGABRT / non-zero exit| D["Respawn only
counter unchanged"]
  C --> E{"Count >= threshold
within interval?"}
  E -->|No| D
  E -->|Yes| F["Master execvp()"]
  F --> G["All pools recycled"]
  G --> H["OPcache wiped"]
  H --> I["Cold-start penalty"]

Common causes

OOM kills themselves do not trip the breaker because they are SIGKILL, not SIGSEGV. But the memory pressure that produced the OOM kills can also corrupt OPcache shared memory, and the genuine SIGSEGVs that follow will count.

Quick checks

Read-only. None of these change state. Kernel log commands require root.

# Confirm the emergency restart happened
grep -i "failed processes threshold\|initiating reload" /var/log/php-fpm/error.log | tail

# Count child deaths by signal in the same window
grep "exited on signal" /var/log/php-fpm/error.log | tail -50

# Confirm the directives are configured (global section, not pool)
php-fpm -tt 2>&1 | grep -E "emergency_restart_(threshold|interval)"

# Kernel view of the segfaults
journalctl -k --since "1 hour ago" | grep -i "segfault\|php"
dmesg -T | grep -i "php\|traps"

# Was there an OOM event nearby?
journalctl -k --since "1 hour ago" | grep -i "out of memory\|oom"
dmesg -T | grep -i "oom"

# Did a deploy happen around the same time? (system-dependent)
journalctl --since "2 hours ago" | grep -i "deploy\|release"

# Master process start time, to bracket the restart
ps -o pid,lstart,etime,cmd -p "$(pgrep -f 'php-fpm: master' | head -1)"

Paths vary by distribution and PHP version. Adjust /var/log/php-fpm/error.log, the PID file, and the master process string to match your system.

How to diagnose it

1. Confirm the breaker actually fired. The threshold log line is the only authoritative evidence. A bare “ready to handle connections” line without it means something else restarted FPM: systemd, an OOM kill of the master, a manual systemctl restart, or a watchdog.
2. Bracket the event in time. Note the timestamp of the threshold message and look back across the previous emergency_restart_interval for child deaths. Deaths outside the window did not contribute.
3. Filter the deaths to SIGSEGV and SIGBUS. Only those count. If the log shows mostly “exited on signal 9” or “exited with code 255”, the threshold count came from a minority of deaths mixed into a larger storm. That minority is the real bug.
4. Pull the per-worker request URI from the moments before the crash. If you have a status poller (Netdata, a custom poller, an APM), look at the last known request URIs for the workers that died. A single recurring URI points at a code path. URIs spread across the application point at shared state: OPcache, an extension global, the PHP runtime itself.
5. Get a core dump if you can. Without rlimit_core = unlimited in the pool config there is nothing to read. With it, coredumpctl list on systemd hosts, or the configured core path otherwise, gives you a backtrace with the exact extension and function. This is the single highest-value artifact for a segfault investigation.
6. Check the deploy timeline. Most emergency restarts in production follow a deploy: new bytecode in OPcache, a new extension version, or a new PHP runtime. If the first event is within minutes of a deploy, treat the deploy as the suspect until ruled out.
7. Decide severity. A single isolated event is a TICKET: investigate, but the restart may have cleared the corruption. Repeated events are a PAGE: there is a persistent bug and the breaker is now part of a crash loop. Each restart costs OPcache warmth, so the loop degrades throughput even between the visible outages.

Metrics and signals to monitor

Fixes

Single isolated event: investigate, do not panic

If the line appears once and the pool recovered, the most likely explanation is transient shared-memory corruption that the restart cleared. Capture the artifacts (log lines, core dumps, deploy timeline) and treat it as a TICKET. Do not roll back yet, and do not raise the threshold to hide the signal.

If you cannot find a core dump and the artifacts are gone, set rlimit_core = unlimited in the pool configuration and reload FPM once, deliberately, so the next crash leaves evidence. This is a one-time setup step, not a fix.

Repeated events: roll back first

When the breaker fires twice within 15 minutes with live traffic, you are in a crash loop. The right first move is rollback, not debugging:

• Roll back the most recent deploy of application code, PHP runtime, or extensions.
• If a specific URI is implicated, block it at the web server layer to protect the rest of the site while you investigate.
• If a specific extension is implicated, disable it in the pool config and reload.

The threshold is not the problem here. Raising emergency_restart_threshold to make the message go away makes things worse: the crash loop continues, workers spend more time dying and respawning than serving requests, and you have removed the only signal that something is wrong.

Breaker never configured: degraded by default

If you expected automatic recovery and instead discovered workers dying in a loop with no threshold message, the directives are at their default of 0. The pool has been running degraded with no circuit breaker. Setting a threshold (typical starting values are emergency_restart_threshold = 10 and emergency_restart_interval = 60) gives you a recovery path and a clear log signal.

These are global directives: they go in the [global] section of php-fpm.conf, not in a pool .conf file. Putting them in a pool file produces an error like unknown entry 'emergency_restart_threshold' and they are ignored.

Restart itself is fragile

If the breaker fires but the master hangs during the restart (workers not draining, the new master slow to come up, the systemd watchdog tripping), the recovery path is the problem. Symptoms include accepted conn staying at zero well past the expected restart window and systemd restarting FPM from the outside. In that case, treat it as a complete service outage and fall back to systemctl restart php-fpm (service name varies by distro: php-fpm, php8.2-fpm, etc.) after confirming the master PID.

Prevention

• Configure the breaker deliberately. The default of 0 is silent degraded operation, not safe operation. Pick a threshold that fits your traffic: low enough to trip on a real crash loop, high enough not to trip on the occasional segfault from a known-flaky extension.
• Put the directives in the global section. Pool files do not honor them. Verify with php-fpm -tt after every config change.
• Set rlimit_core = unlimited on production pools. Without core dumps, every segfault investigation starts from nothing.
• Bound per-worker RSS with pm.max_requests. Unbounded RSS growth leads to OOM pressure, which can corrupt OPcache shared memory and produce the genuine SIGSEGVs that trip the breaker. The leak itself does not count, but the corruption it causes does.
• Correlate deploys with crash events. A deploy hook that records a timestamp somewhere pollable (a log line, a file, a metric label) turns “did the deploy cause this?” from an archaeology project into a one-line query.
• Watch OPcache memory pressure. oom_restarts > 0 from opcache_get_status() is a leading indicator of the kind of shared-memory corruption that produces segfaults.
• Do not raise the threshold to suppress noise. If the breaker is firing, the workers are crashing. Suppressing the signal does not stop the crashes.

How Netdata helps

• The PHP-FPM collector surfaces status page counters (accepted conn, active processes, idle processes, max children reached, listen queue) at per-second resolution, so the dip-and-recover shape of an emergency restart is visible as a sharp reset to zero rather than a gradual trend that polls miss.
• Worker exit signals from the error log, filtered to SIGSEGV and SIGBUS, line up against the threshold log line on the same timeline. The deaths that tripped the breaker are visible in the seconds before the restart, not just inferred afterward.
• OPcache hit rate, memory usage, and `oom_restarts` sit next to the pool metrics, so the cold-start penalty after the restart is easy to separate from the original crash.
• ML anomaly detection on accepted connections and active worker count flags the restart window even when no static threshold would have fired, which matters when the breaker is misconfigured to 0 and the only signal is degraded throughput.
• cgroup memory pressure (memory.events.oom_kill, memory.current versus memory.max) correlates with worker deaths on containerized deployments, where the OOM killer can precede the OPcache corruption that actually trips the breaker.
• Master process uptime (from the status page start_since field) confirms the restart happened at all, which is the first question when a status page counter has reset to zero and nobody knows why.

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