Operations 7 min read

How to Diagnose and Raise Linux Resource Limits for Files, Stack, and Processes

This article explains why Linux imposes resource limits, shows how to inspect user‑level limits with ulimit, demonstrates practical experiments to increase file‑descriptor and stack limits via /etc/security/limits.conf, and outlines system‑wide constraints and tools like prlimit for robust server programming.

Liangxu Linux
Liangxu Linux
Liangxu Linux
How to Diagnose and Raise Linux Resource Limits for Files, Stack, and Processes

Introduction

Linux enforces various resource limits to prevent a single process from exhausting system resources. Hitting these limits—such as leaving a file descriptor open, encountering malloc failures, or stack overflow—can cause severe failures. Understanding and adjusting these limits is essential for reliable server development.

User‑Level Resource Limits

The ulimit command displays per‑user limits defined in /etc/security/limits.conf (and files under /etc/security/limits.d). These limits affect only users logged in via PAM and do not apply to system services.

Key limits include:

Stack size ( -s): 8 MB

Maximum number of processes ( -u): ~30 000

Open file descriptors ( -n): 1024

Use ulimit -a to view all soft limits and ulimit -Ha or ulimit -Sa for hard limits. Only root can raise hard limits; regular users can lower them.

Experiment 1 – Raising the File‑Descriptor Limit

Add the following lines to /etc/security/limits.conf (or a file in /etc/security/limits.d) and reboot to make the change permanent:

*               soft    nofile          10240
*               hard    nofile          10240

After reboot, verify the new limit with ulimit -n. A test program that attempts to open 10 240 temporary files reports success up to 10 217 descriptors, confirming the limit increase (the shortfall is due to files already opened by the program, libraries, and standard streams).

Experiment 2 – Raising the Stack Size

Append the following lines to /etc/security/limits.conf:

*               soft    stack           8192000
*               hard    stack           8192000

Compile and run a C program that recursively allocates stack frames. When the stack reaches the new soft limit, the program crashes with a segmentation fault, indicating the practical ceiling of roughly 8 MB.

System‑Level Resource Limits

Kernel‑level constraints are not configurable via ulimit. Important system limits include:

Maximum file handles per process: 1 000 000 000

PID range limit: ~4 000 000

Global file descriptor limit ( file‑max): 6 000 000

Total threads system‑wide: 60 000

Maximum memory‑mapped regions per process: 60 000

Redis File‑Descriptor Example

Redis logs a message such as

Increased maximum number of open files to 10032 (it was originally set to 1024)

after adjusting its limits. Internally it calls setrlimit(RLIMIT_NOFILE,&limit) to raise the descriptor ceiling temporarily.

setrlimit(RLIMIT_NOFILE, &limit);

prlimit – An Alternative to ulimit

The prlimit command can query or set resource limits for a running process, offering functionality similar to ulimit but with per‑process granularity.

Conclusion

Linux resource limits are crucial for maximizing performance and preventing resource exhaustion. Developers of server‑side applications should inspect and, when necessary, raise limits via /etc/security/limits.conf (or use prlimit) to ensure their programs can handle the required load.

Linuxulimitfile-descriptorsresource limitsprlimitStack Size
Liangxu Linux
Written by

Liangxu Linux

Liangxu, a self‑taught IT professional now working as a Linux development engineer at a Fortune 500 multinational, shares extensive Linux knowledge—fundamentals, applications, tools, plus Git, databases, Raspberry Pi, etc. (Reply “Linux” to receive essential resources.)

0 followers
Reader feedback

How this landed with the community

Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.