Troubleshooting Too Many Open Files on a Linux VPS

The error too many open files does not necessarily mean your application has opened thousands of documents. Linux file descriptors also represent sockets, pipes, and other resources. A busy web service may reach a descriptor limit through network connections, while a quiet process may reach it because it never closes something. Increasing the limit is useful only after you understand which case you have.

Locate the affected process and limit

Read the application error and identify the process or service that emitted it. Inspect its effective limits through the process's /proc entry or your service manager's status tools. The value shown by ulimit -n in your SSH shell does not automatically describe a separately launched system service. Linux distinguishes soft and hard resource limits; the getrlimit manual documents the underlying model. Record the limit actually applied to the failing process.

Observe what the descriptors represent

Use an appropriate process inspection tool to classify open descriptors into network sockets, ordinary files, pipes, or deleted files. Keep the output private because paths and connection details can expose internal information. Sample the count over time instead of collecting a huge unbounded dump during a busy incident. Compare it with active request count, worker count, and dependency connections. A descriptor total that tracks legitimate concurrency has a different explanation from one that rises continuously after traffic stops.

Work through two common patterns

In one illustrative case, a reverse proxy reaches its configured descriptor limit during a predictable connection surge and returns errors. Capacity and connection settings deserve review together. In another case, a background worker opens a new log or network connection for every job and leaves it open. The count grows by roughly one for every completed task, even when jobs run slowly. Raising the limit in the second case merely postpones failure; the application must close resources or use a bounded pool correctly.

Adjust the owning service deliberately

If measured legitimate demand requires a higher limit, configure it through the mechanism that launches the process. For systemd services, consult the systemd execution settings and the application's own compatibility requirements. Increasing an operating-system limit does not automatically raise a reverse proxy's connection limit or a database's pool capacity. Review related memory and upstream resource demand, then apply the change during an appropriate restart window and confirm the new process received it.

Verify steady behavior after the change

Repeat a bounded representative workload and watch descriptor use rise and fall as connections or jobs complete. Check error rates and customer latency, not just whether the original message stopped appearing. If the count remains elevated indefinitely, investigate idle-connection policy or a possible leak. Add a trend alert with enough warning to inspect the process before it reaches the limit again. Preserve the effective setting in your deployment and recovery records.

Use LayerOne documentation for guest access and service operations. If legitimate workload growth also increases CPU or memory demand, compare the current VPS resources. The goal is a bounded, understood connection model that fits both the process limits and the rest of the application.