Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I'd like to understand what's going on here.

linvx$ ( ulimit -u 123; /bin/echo nst )
nst

linvx$ ( ulimit -u 122; /bin/echo nst )
-bash: fork: Resource temporarily unavailable
Terminated

linvx$ ( ulimit -u 123; /bin/echo one; /bin/echo two; /bin/echo three )
one
two
three

linvx$ ( ulimit -u 123; /bin/echo one & /bin/echo two & /bin/echo three )
-bash: fork: Resource temporarily unavailable
Terminated
one

I speculate that the first 122 processes are consumed by Bash itself, and that the remaining ulimit governs how many concurrent processes I am allowed to have. The documentation is not very clear on this. Am I missing something?

More importantly, for a real-world deployment, how can I know what sort of ulimit is realistic? It's a long-running daemon which spawns worker threads on demand, and reaps them when the load decreases. I've had it spin the server to its death a few times. The most important limit is probably memory, which I have now limited to 200M per process, but I'd like to figure out how I can enforce a limit on the number of children (the program does allow me to configure a maximum, but how do I know there are no bugs in that part of the code?)


Addendum: On a newer system, I get a higher number and slightly different behavior.

xubuntu12.04$ ( ulimit -u 206; /bin/echo nst )
nst

xubuntu12.04$ ( ulimit -u 205; /bin/echo nst )
bash: fork: retry: No child processes
bash: fork: retry: No child processes
bash: fork: retry: No child processes
bash: fork: retry: No child processes
bash: fork: Resource temporarily unavailable
Terminated

xubuntu12.04$ bash --version
GNU bash, version 4.2.24(1)-release (x86_64-pc-linux-gnu)
Copyright (C) 2011 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>

This is free software; you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

The older system had Bash v3 I believe.

In dash, I get different behavior, albeit still not the behavior I expect (and the option is called -p instead of -u):

xubuntu12.04$ dash

$ ( ulimit -p 1; /bin/echo nst )
nst

$ ( ulimit -p 2; /bin/echo nst & /bin/echo too & )
dash: 0: Cannot fork

$ ( ulimit -p 208; /bin/echo nst & /bin/echo too & )
dash: 0: Cannot fork
nst

$ ( ulimit -p 209; /bin/echo nst & /bin/echo too & )
nst
too
share|improve this question

2 Answers 2

up vote 3 down vote accepted

It's not only the subprocesses in the subshell that count against the limit, but everything on the system under your uid.

Thus, if you have 200 processes running as yourself anywhere on the system, a process with ulimit -u 205 will only be able to fork until the total count reaches 205 -- that is, five times (if nothing exits).

share|improve this answer
    
Threads also count against the limit too, not just processes. –  Matthew Ife Apr 20 '13 at 15:50
1  
@Mlfe For POSIX threads on modern Linux, yes. Hmm; I suppose not many systems/runtimes use green threads these days. –  Charles Duffy Apr 20 '13 at 19:08

This is the way ulimit works.

If you wish to allow one user 4 running processes,

you would have 1+4 (one is for the bash process that the user is currently using)

From my tests,

created a user test,

ran ulimit -u 1

could not run any commands as bash already a running process,

ran ulimit -u 2

can only run one process, example,

ps aux -> returned value but ps aux | grep test -> did not return as it's using 2 processes

Lastly using ulimit on your root account is not recommended, ulimit is mostly used for large multi user environments.

I hope this helps!

Cheers,

===============

 -a     All current limits are reported
 -b     The maximum socket buffer size
 -c     The maximum size of core files created
 -d     The maximum size of a process’s data segment
 -e     The maximum scheduling priority ("nice")
 -f     The maximum size of files written by the shell and its children
 -i     The maximum number of pending signals
 -l     The maximum size that may be locked into memory
 -m     The maximum resident set size (many systems do not honor this limit)
 -n     The maximum number of open file descriptors (most systems do not allow  this
                     value to be set)
 -p     The pipe size in 512-byte blocks (this may not be set)
 -q     The maximum number of bytes in POSIX message queues
 -r     The maximum real-time scheduling priority
 -s     The maximum stack size
 -t     The maximum amount of cpu time in seconds
 -u     The maximum number of processes available to a single user
 -v     The maximum amount of virtual memory available to the shell
 -x     The maximum number of file locks
 -T     The maximum number of threads
share|improve this answer
    
This does not explain why Bash will not run a single process when you set the corresponding ulimit to something like 50. –  tripleee Jan 22 '13 at 14:25
1  
@tripleee You were logged in to an X desktop session, which spawns dozens of processes under your user account. –  Michael Hampton Jan 22 '13 at 17:58
    
For launching /bin/echo in a subshell? Really? Anyway, the original problem report was definitely from a server which doesn't have X11. –  tripleee Jan 23 '13 at 6:54
    
Are you running as root or as a user? –  Danie Jan 23 '13 at 7:18
1  
@triplee It's not only the processes in the subshell counted against the limit. –  Charles Duffy Apr 19 '13 at 17:35

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.