🚨 Logstash Error: 'Too many open files' — Cause, Fix, and Troubleshooting Guide

What this error means

Every file Logstash tails, every socket it holds open to Elasticsearch or Kafka, and every persistent-queue page it maps counts against the process file-descriptor limit. When the JVM asks the kernel for one more descriptor and there are none left, the request fails with EMFILE and Logstash logs an uncaught exception:

[ERROR][logstash.inputs.file ][main] Uncaught exception (Errno::EMFILE) Too many open files - /var/log/app/2026-07-12.log

You may also see the same limit surface from the JVM itself as an I/O exception:

java.io.IOException: Too many open files

This is not a Logstash bug — it is the process hitting the descriptor ceiling. The file input is the usual culprit because it keeps a handle open on every log it tails, and a broad glob over a directory of rotated logs can pin thousands of handles at once. Add the open ES/Kafka output sockets and the mapped persistent-queue pages on top of that, and a heavy fan-in pipeline blows straight past the default limit.

Warning signs

• (Errno::EMFILE) Too many open files or java.io.IOException: Too many open files in logstash-plain.log.
• The file input stops picking up new or rotated logs; ingest from that input stalls.
• Output connections to Elasticsearch or Kafka fail to open because no descriptors remain.
• The error appears under load — after a log-rotation burst or when a wide glob suddenly matches many files — not at a clean startup.
• lsof -p <pid> shows a huge count of open regular files, most of them old rotated logs the pipeline no longer needs.

Measuring the limit

First find the running process and count exactly how many descriptors it holds right now. If that number is near the configured limit, you have your answer:

# Current open FDs for the Logstash process
ls -1 /proc/$(pgrep -f 'logstash')/fd | wc -l

# The limit the process is actually running under
cat /proc/$(pgrep -f 'logstash')/limits | grep 'open files'

Break the count down by type so you know whether files, sockets, or queue pages dominate:

# What is Logstash holding open, and how many of each?
lsof -p $(pgrep -f 'logstash') | awk '{print $5}' | sort | uniq -c | sort -rn

# How many of them are the file input's rotated logs?
lsof -p $(pgrep -f 'logstash') | grep '/var/log/app/' | wc -l

Inspect the file input for a glob that is matching far more than it should. Logstash .conf files use a Ruby-like DSL, so the input is shown as ruby:

input {
  file {
    path => "/var/log/app/**/*.log"   # matches every rotated file too
    start_position => "beginning"
    sincedb_path => "/var/lib/logstash/sincedb_app"
  }
}

If a path like that expands to thousands of files, the input will try to open all of them and exhaust the descriptors on its own.

Limits and pressure causes

• File-descriptor limit too low for the fan-in — the packaged systemd unit ships LimitNOFILE=16384, and a pipeline tailing many logs plus open sockets and queue pages exceeds it.
• A greedy glob in the file input — a pattern like /var/log/app/**/*.log matches thousands of rotated files, each of which the input opens and holds.
• No close_older / ignore_older — the input keeps handles open on files that stopped being written long ago instead of releasing them.
• Persistent queue page pressure — a large PQ maps many page files, adding to the descriptor count that competes with inputs and outputs.
• Many output sockets — a large connection pool to ES or Kafka multiplies open sockets on top of the file handles.

Remediation

Raise the limit with a systemd drop-in override rather than editing the packaged unit, which a package upgrade would overwrite. Run systemctl edit logstash and add:

[Service]
LimitNOFILE=65536

Then reload systemd and restart so the new limit takes effect:

sudo systemctl daemon-reload
sudo systemctl restart logstash
cat /proc/$(pgrep -f 'logstash')/limits | grep 'open files'   # confirm 65536

Then stop the file input from hoarding handles. Release files that have gone quiet with close_older, and never open long-dead ones with ignore_older. Also tighten the glob so it does not sweep in rotated archives:

input {
  file {
    path => "/var/log/app/current/*.log"   # only the active log dir, not **
    start_position => "beginning"
    sincedb_path => "/var/lib/logstash/sincedb_app"
    close_older  => "1 hour"    # release handles for files idle > 1h
    ignore_older => "2 days"    # never open files older than 2 days
  }
}

Raising LimitNOFILE buys headroom; close_older/ignore_older and a tight glob stop the input from consuming that headroom in the first place. You generally want both.

Capacity headroom

• Raising LimitNOFILE without fixing a greedy glob just delays the same crash — the handle count will climb back to the new ceiling.
• close_older releases a handle, but if the file is still being written Logstash reopens it on the next discovery cycle; set it long enough to avoid churn.
• ignore_older is evaluated against file mtime — if an archived log is touched, it can be re-opened. Keep truly old logs out of the input path.
• Edits under systemctl edit land in a drop-in, but you must daemon-reload and restart for a new LimitNOFILE to apply; a plain reload of the pipeline does not change process limits.
• Persistent-queue pages and output sockets also count — if you run a large PQ or a big output pool, budget descriptors for them too.

Related capacity errors

• Fix Logstash Java heap space OutOfMemoryError
• Recover from a corrupt Logstash persistent queue
• Resolve the Logstash ‘another instance’ lock error