$ guides / php-fpm / php-fpm-too-many-open-files ▌

Operations Guides

PHP-FPM "Too many open files": file descriptor exhaustion

The signature line in the PHP-FPM error log is:

ERROR: failed to prepare the stderr pipe: Too many open files (24)

The (24) is the C errno EMFILE: the calling process has hit its per-process open file descriptor limit. By the time this line appears, the master has already failed to fork a usable child, and application code has probably been failing intermittently for minutes beforehand with random connection refusals, unreadable files, and sessions that refuse to start.

Operators get stuck on this error because there are three independent layers of limits, and changing only one of them changes nothing. The OS ulimit -n, the systemd unit’s LimitNOFILE, and PHP-FPM’s own rlimit_files directive (global in php-fpm.conf for the master, and per-pool for the children) all apply. On any host where systemd starts PHP-FPM, /etc/security/limits.conf is silently ignored for the service.

What this means

Every PHP-FPM worker is a full process that holds file descriptors for: the FastCGI listen socket, the communication pipes back to the master, every PHP source file the autoloader has touched, persistent database and cache connections, session files, log streams, and any socket opened by application code or extensions. The default soft limit of 1024 open files per process is generous for a login shell and tight for a worker that fans out to a database, a cache, and a hundred framework includes per request.

There are two distinct exhaustion modes, and the error log only reports one of them:

Master exhaustion. The master process holds its end of the communication pipes for every child. With the default limit of 1024, a pool sized near pm.max_children = 500 consumes roughly 1000 FDs in the master alone (about two pipe ends per child), plus the listen socket and its own bookkeeping. When the master cannot allocate the stderr pipe for the next child, you get the error above and the pool stops growing.
Worker exhaustion. A single worker leaks or accumulates FDs and hits its own 1024 limit. The master never logs this directly. Application code sees fopen(), fsockopen(), session_start(), or PDO connection calls fail with “Too many open files” and the request returns a 500. The error appears in the application error log, not the FPM error log.

The first response to either mode is the same: check /proc/<pid>/limits and /proc/<pid>/fd, then decide whether the limit is just too low for the configured workload or whether something is leaking.

flowchart TD
    A["EMFILE in FPM error log"] --> B{"Error mentions
'stderr pipe'?"}
    B -- Yes --> M["Master hit its FD limit"]
    B -- No, app log only --> W["Worker hit its FD limit"]
    M --> C["cat /proc/master/limits
ls /proc/master/fd"]
    W --> C2["ls /proc/worker/fd
sampled over time"]
    C --> D{"FD count near limit
only under load?"}
    C2 --> D2{"FD count climbs
and never returns
to baseline?"}
    D -- Yes --> E["Raise limit:
LimitNOFILE + rlimit_files"]
    D2 -- Yes --> F["Leak suspected:
strace the worker"]
    F --> G["grep EMFILE or
open without close"]

Common causes

Cause	What it looks like	First thing to check
Master FD limit too low for `pm.max_children`	“failed to prepare the stderr pipe” appears as the pool scales toward `max_children`; clears when traffic drops	`cat /proc/<master_pid>/limits`
systemd `LimitNOFILE` not raised	Raised `rlimit_files` but error persists, or vice versa	`systemctl show php-fpm -p LimitNOFILE`
FD leak in an extension or in `system()` / `proc_open()` calls	Per-worker FD count climbs monotonically and never returns to baseline between requests	`ls /proc/<worker_pid>/fd \| wc -l` sampled over time
Default 1024 limit with a fan-out workload	Intermittent `EMFILE` only during peak traffic, with no leak pattern	Effective limit from `/proc/<pid>/limits`

Quick checks

These are all read-only and safe to run during an incident.

# Find the master and a sample worker PID
pgrep -af "php-fpm: master"
pgrep -af "php-fpm: pool"

# Show the actual soft and hard FD limits the process is running with
cat /proc/<master_pid>/limits | grep -i "open files"
cat /proc/<worker_pid>/limits | grep -i "open files"

# Count live FDs in each
ls /proc/<master_pid>/fd | wc -l
ls /proc/<worker_pid>/fd | wc -l

# List what the FDs actually are (sockets, pipes, regular files)
ls -l /proc/<worker_pid>/fd | tail -30

# Confirm what systemd applied to the service
systemctl show php-fpm -p LimitNOFILE -p LimitNOFILESoft

# Confirm what PHP-FPM thinks rlimit_files is (does not require a restart)
php-fpm -tt 2>&1 | grep -i rlimit_files

The two checks that matter most are /proc/<pid>/limits (what the kernel will actually enforce) and ls /proc/<pid>/fd | wc -l (how close you are). If rlimit_files in the pool config disagrees with /proc/<pid>/limits, the lower effective value wins, and the master applies rlimit_files to children at fork time.

How to diagnose it

Identify which process is exhausted. If the error is in the FPM error log and mentions the stderr pipe, the master is the victim. If the error is only in the application log and mentions fopen, PDO, or session_start, a worker is the victim. Both can be true at once.
Read the effective limits from /proc. Do not trust ulimit -n from your interactive shell; the shell does not share the service’s limits. cat /proc/<pid>/limits is the only source of truth for what the running process actually has.
Check the FD count under load and at idle. A healthy worker’s FD count fluctuates with the request and returns to a low baseline between requests. A worker whose FD count only ever goes up is leaking.
Decide: ceiling or leak. If FD count is well below the limit at idle and only spikes during traffic peaks, the limit is too low for the workload. If FD count creeps upward regardless of traffic, something is failing to close().
Trace the leak if present. Attach strace to a single suspect worker. This briefly perturbs that worker, so attach to one, not all of them, and only in a controlled window:
```
# Trace one worker and look for opens without matching closes
strace -p <worker_pid> -f -e trace=openat,open,socket,close -o /tmp/fpm-fd.trace
```
Then grep the trace for EMFILE returns and for openat or socket calls that have no corresponding close. A common pattern is an extension that opens a handle per request and only releases it on worker shutdown.
Check the math against max_children. Multiply max_children by the number of FDs each child costs the master (roughly two for the communication pipes) and add the master’s own overhead. If that product is near the master’s limit, the master will hit the wall before the pool is full.

Metrics and signals to monitor

Signal	Why it matters	Warning sign
Per-process open FD count (`/proc/<pid>/fd`)	The direct leading indicator; the error log only fires after the limit is hit	Sustained upward trend in any single worker, or master FD count above 70% of its limit
Effective `Max open files` from `/proc/<pid>/limits`	Confirms which layer is actually binding	Soft limit still at 1024 after a config change, meaning the change did not take effect
`pm.max_children` vs master FD headroom	The master holds pipes per child; high `max_children` tightens the master’s budget	Master FD usage scaling linearly with worker count
Worker exit and respawn rate	A leak masked by `pm.max_requests` recycling shows up as elevated churn	Exits correlated with FD count returning to baseline
Web server 502 rate	The user-visible symptom once the pool cannot grow or workers fail internally	502s rising alongside master FD saturation

Fixes

Raise the limit, in every layer that applies

The reliable order is:

systemd unit override. On systemd hosts this is the authoritative source. Do not edit /etc/security/limits.conf; systemd does not read it for services. Use the override mechanism:
```
# Open the override editor (creates the drop-in for you)
systemctl edit php-fpm.service
```
Add:
```
[Service]
LimitNOFILE=65536
```
Then reload systemd and restart PHP-FPM:
```
systemctl daemon-reload
systemctl restart php-fpm.service
```
The unit name varies by distro and PHP version: php-fpm.service on RHEL-family, php8.2-fpm.service (or similar) on Debian and Ubuntu. Adjust accordingly.
PHP-FPM rlimit_files. Set the global directive in php-fpm.conf for the master, and the per-pool directive in each pool config for the children. If you omit the global one, the master keeps the systemd limit, which is usually fine. If you omit the per-pool one, children inherit the master’s limit.
```
; php-fpm.conf, [global] section
rlimit_files = 65536

; pool config, e.g. /etc/php/8.2/fpm/pool.d/www.conf
pm.max_children = 200
rlimit_files = 65536
```
Containers. Docker and other runtimes apply their own ulimit defaults at container start. Set the ulimit explicitly so the limit inside the container matches your intent:
```
docker run --ulimit nofile=65536:65536 ...
```
In Compose:
```
services:
  php-fpm:
    ulimits:
      nofile:
        soft: 65536
        hard: 65536
```
Some recent Docker daemon versions ship a very high default nofile (on the order of 1048576). That is not a bug, but a few libraries iterate over the full FD range and slow down as a result. Pick an explicit, finite value rather than inheriting the daemon default.

After any change, verify with /proc/<pid>/limits. If the soft limit did not move, the change did not take effect. The most common reasons are forgetting systemctl daemon-reload, editing the wrong pool file, or the service being managed by a control panel (cPanel, Plesk) that regenerates configs and overwrites manual edits.

Cap the leak with `pm.max_requests`

If the FD count climbs without bound, raising the limit only delays the failure. The pragmatic mitigation is to recycle workers on a request budget so leaked FDs are released when the worker exits:

pm.max_requests = 500

This is the same defense used against memory leaks. It does not fix the leak; it bounds its blast radius. Pair it with the investigation in the diagnosis section so the root cause is found rather than papered over.

Address extension and call-site leaks

PHP Bug #76802 documents that workers calling system() or proc_open() leak the worker’s inherited FDs (including the FastCGI socket) to the spawned child process. This is both an FD leak and a security concern. If the application shells out frequently from the request path, that is a prime suspect for monotonic FD growth.

For application-level leaks, prefer proc_open() with explicitly controlled descriptors rather than system(), and ensure every fopen, fsockopen, and PDO handle is closed or goes out of scope before the request ends. Persistent connections (PDO ATTR_PERSISTENT, persistent Redis handles) intentionally hold FDs across requests; count them as part of the baseline, not as a leak.

Prevention

Set the FD limit deliberately at provisioning time, in the systemd unit or container spec. Inherited defaults are too low for FPM and silently ignored when wrong.
Size max_children against the master’s FD budget, not just memory. A 200-worker pool costs the master roughly 400 FDs in communication pipes before any request is served.
Monitor per-worker FD count. The error log is a trailing indicator; a slow upward trend is the leading sign of a leak.
Set pm.max_requests as a universal safety net, the same way you would for memory, to bound the impact of any leak you have not yet found.
Avoid system() on hot paths. Prefer proc_open() with explicit descriptors, or move the work out of the request path entirely.

How Netdata helps

Netdata collects per-process file descriptor counts at per-second resolution, so a slow FD leak in a single worker is visible as a climbing line long before the worker hits EMFILE.
The PHP-FPM collector surfaces active processes, idle processes, total processes, and the max children reached counter alongside per-process FD usage, so you can correlate a master FD spike with a pool scaling event toward max_children.
Correlating per-worker FD count with the web server’s 502 rate and FPM’s accepted connections rate distinguishes a master-side ceiling (502s rise as the pool fails to grow) from a worker-side leak (application 500s rise while the pool itself looks healthy).
Per-second resolution shows whether FD count returns to baseline between requests (healthy) or ratchets upward (leak), which is the single most important distinction for this class of problem.