Linux /etc/security/limits.conf explanation
Can anyone explain (or know of a source) that provides details about the items in limits.conf? The man page doesn't give much detail.
For example it says:
rtprio
maximum realtime priority allowed for non-privileged processes (Linux 2.6.12 and higher)
priority
the priority to run user process with (negative values boost process priority)
How are these different? What values can they take? What do they default to?
Some of the items are obvious, but where can I find better explanations (default values, ranges, what they actually mean etc) of:
data
maximum data size (KB)
fsize
maximum filesize (KB)
memlock
maximum locked-in-memory address space (KB)
cpu
maximum CPU time (minutes)
nice
maximum nice priority allowed to raise to (Linux 2.6.12 and higher) values: [-20,19]
What happens when the CPU is exceeded? The processes are killed? Only one process or the whole user is banned from using the CPU? Is this for one session or for a maximum time in each minute?
I tried to find answers but all I can find is the one man page that provides almost no details at all.
rtprio
maximum realtime priority allowed for non-privileged processes (Linux 2.6.12 and higher)
priority
the priority to run user process with (negative values boost process priority)
Why are these different?
There are different classes of process schedulers on linux. The default one (CFQ) basically gives an equal amount of time slices to each process wanting to run and queues runnable tasks in such a way that everyone waits on average an equal amount of time for their turn. Some exceptions to this rule exist but thats the basic idea.
Another class of scheduler is the realtime scheduler. Realtime is a little different, rather queue runnable tasks into a fair queuing scheme, the realtime process will get CPU time as soon as it is needed by the process, this evict a running process from the CPU in order to make room for the 'realtime' process.
What values can they take?
What 'priority' does is alter the niceness of procesess so that on login your main process starts at a certain niceness, any child processes you spawn also start at the same niceness.
This has the effect of making it more likely to be scheduled in in favour of other competing processes and the user experience can be made to either be more responsive/interactive for the lower niceness values and less responsive/interactive if the niceness is raised.
It may be important for normal login users to have a lower priority than serviceable daemons for example, or root to have a higher priority on login than everything else.
As for realtime, contention is handled with the 'rtprio' field. If you have two realtime tasks both wanting to run then the 'rtprio' value is used to determine which of the processes to pick for priority first. A higher rtprio produces higher priority tasks.
Setting this in the limits.conf permits realtime tasks to be set at a particular priority banding without needing root to set the value. This has no effect on tasks not set to run using a realtime scheduler.
The 'nice' value should do the same as 'rtprio' but for standard CFQ scheduling. I've never tried it though. It sets the initial process spawned when PAM is setting these limits to that nice vaule, a normal user can then go to that nice level or higher without needing root to set them. If you dont renice explicitly it means all processes spawned from a shell from that login (for example) will inherit the nice value set in the limits.conf form the parent process that was initially created.
What are the defaults?
The 'default' limits -- technically are them all being set to what pid 1 is unless explicitly set, resource limits are inherited from the parent process, if no limits have been defined or overridden anywhere then the inheritance from init is the default.
Other Values
data
maximum data size (KB)
When a process is initialized, it allocates some memory known as the 'data segment' when the process is copied into memory, this is where the space for globals, perhaps some other initialized data and memory allocated from the heap lives. The limit controls the maximum allocated amount that a process can take.
Its unlikely you'll ever hit this limit because malloc() rarely over-uses the data segment to store data.
fsize
maximum filesize (KB)
This literally just sets the maximum size that a file can be written to as with that user.
memlock
maximum locked-in-memory address space (KB)
Nearly all memory that an application has acquired is 'evictable'. That is can be swapped out. Memory locked memory is never swappable and remains resident. This value is strictly controlled because it can be abused by people to starve a system of memory and cause swapping. It is typically useful with security applications (which never want their pages swapped -- and becoming readable from the swap partition).
cpu
maximum CPU time (minutes)
This represents the total amount of time a process can consume on a CPU. A process that exceeds this value is killed. Note this is NOT the same as the amount of time that has elapsed since the process was started. I.E a cputime limit of 1 minute would take 1 minute to be consumed if the process had 100% cpu utilization, but 2 minutes to consume if the process used 50% utilization.
What happens whem cpu is exceeded?
The process gets sent a kill signal SIGXCPU which terminates the process. This can then be caught by the parent process and handled there.
Only one process or the whole user is banded from using the CPU?
Nearly all the limits referenced are handled on a per-process basis. CPU time included. The only ones that are not I believe to be the total number of logins and the total number of processes by that user.
Some other gotches with limits are:
- Max processes includes the number of lightweight threads.
- The RSS limit does nothing and has not for a number of years, its pointless to set.
This is for the pam_limits module... it is setrlimit(2) and sysctl(8) values. My search didn't unearth any hard limits, but the cited man pages give some explanations.