Linux /etc/security/limits.conf explanation

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.