Context
A service reports too many open files even though an administrator's terminal has a generous ulimit. File descriptors are process-owned handles for resources such as sockets, files and pipes. The service's running process has its own inherited limits, and the administrator's shell is not evidence of those values.
Prepare the service name, exact error text, process identity and time of failure. Determine whether the application is single-process or uses workers with separate descriptor tables. Read-only inspection usually suffices to establish the initial cause. Avoid changing system-wide limits before identifying the affected process and its workload.
Compare use with the live limit
- Find the main PID with
systemctl show example.service -p MainPIDand identify any workers through the application's process model. Read/proc/PID/limitsfor the relevant process. Record soft and hard open-file limits, replacing PID with the verified number. Limits displayed for a manager process may differ from those applied by a child that changes its own settings. - Inspect
/proc/PID/fdthrough approved administrative access and count entries at meaningful workload intervals. Link targets can reveal sensitive filenames, so summarize resource types rather than publishing a raw listing. Determine whether descriptors rise with active connections and then return toward baseline, or continue accumulating after work completes. - Compare
systemctl show example.service -p LimitNOFILE -p LimitNOFILESoftand the unit's drop-ins with the running limits. A configuration change does not retroactively alter an existing process. Review application documentation for internal connection pools, file-handle retention and any supported method of raising its soft limit within the hard limit.
An illustrative connection leak
In an illustrative export API, descriptor use climbs after each canceled download and does not return after requests finish. Raising the limit delays failure, but the trend remains. The application must release the abandoned resources; the operations team can use the measured growth and resource types to give developers a reproducible investigation rather than an arbitrary capacity recommendation.
| Evidence | Interpretation | Next check |
|---|---|---|
| Live use approaches soft limit | Process-level exhaustion | Legitimate demand versus leaked handles |
| Shell limit differs from service | Different execution context | Unit and process inheritance |
| New configured limit, old process limit | Change not activated | Service lifecycle |
| Several workers differ | Per-process behavior | Worker initialization and workload distribution |
Correct the measured constraint
If demand is legitimate, size a service-specific limit with the application owner and test the implementation's supported event mechanism. systemd warns that software using select() cannot handle descriptors above its supported descriptor-number range. A larger soft limit is therefore not automatically safe for every legacy program.
If use grows without a workload explanation, prioritize the leak or pool-lifecycle correction. Any temporary limit increase should have an owner and a removal or review condition. Preserve capacity for other processes and avoid implying that a high limit reserves actual memory or guarantees throughput.
Validate through representative connection churn and cancellation behavior. Confirm the running limits after the intended service activation, observe descriptor use returning appropriately and verify ordinary requests remain successful. Compare the same workload and duration so the result addresses the original failure pattern.
Maintain service-level evidence
Monitor descriptor use relative to the live soft limit and watch sustained growth separately from normal peaks. Document workers, expected pools, limit ownership and restart requirements. Include the descriptor trend in incident handoffs. Clouvenix server performance can help distinguish capacity from resource-lifecycle faults.