Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

The default nofile limit for OS X user accounts seems to be about 256 file descriptors these days. I'm trying to test some software that needs a lot more connections than that open at once.

On a typical debian box running the pam limits module, I'd edit /etc/security/limits.conf to set higher limits for the user that will be running the software, but I'm mystified where to set these limits in OS X.

Is there a GUI somewhere for it? Is there a config file somewhere for it? What's the tidiest way to change the default ulimits on OS X?

share|improve this question
For Mac OS X Lion, see – David James Aug 27 '12 at 13:14
up vote 23 down vote accepted

Under Leopard the initial process is launchd. The default ulimits of each process are inherited from launchd. For reference the default (compiled in) limits are

$ sudo launchctl limit
    cpu         unlimited      unlimited      
    filesize    unlimited      unlimited      
    data        6291456        unlimited      
    stack       8388608        67104768       
    core        0              unlimited      
    rss         unlimited      unlimited      
    memlock     unlimited      unlimited      
    maxproc     266            532            
    maxfiles    256            unlimited

To change any of these limits, add a line (you may need to create the file first) to /etc/launchd.conf, the arguments are the same as passed to the launchctl command. For example

echo "limit maxfiles 1024 unlimited" | sudo tee -a /etc/launchd.conf

However launchd has already started your login shell, so the simplest way to make these changes take effect is to restart our machine. (Use >> to append to /etc/launchd.conf.)

share|improve this answer
Could you add a link to the official documentation for this? – Glyph Jan 6 '10 at 4:09
Dude, if this was documented anywhere, this page wouldn't be needed – Dave Cheney Jan 24 '10 at 1:07
Doesn't seem to work on Snow Leopard. – ismail Oct 26 '10 at 21:41
Any idea how this differs from sysctl.maxfiles? (related question: – keflavich Dec 14 '11 at 18:01
Small correction: you're running echo under sudo but trying to have your unprivileged shell append to the file, which it doesn't have permission to do. Try echo "limit maxfiles 1024 unlimited" | sudo tee -a /etc/launchd.conf instead. – Vineet Mar 31 '13 at 22:24
sudo echo "limit maxfiles 1024 unlimited" >> /etc/launchd.conf

does not work because sudo is in the wrong place, try this:

echo 'limit maxfiles 10000 unlimited' | sudo tee -a /etc/launchd.conf
share|improve this answer
This would probably be better as a “suggested edit” for the answer to which you are referring. – Chris Johnsen Mar 8 '13 at 9:33
% ulimit -a
core file size          (blocks, -c) 0
data seg size           (kbytes, -d) 6144
file size               (blocks, -f) unlimited
max locked memory       (kbytes, -l) unlimited
max memory size         (kbytes, -m) unlimited
open files                      (-n) 2560
pipe size            (512 bytes, -p) 1
stack size              (kbytes, -s) 8192
cpu time               (seconds, -t) unlimited
max user processes              (-u) 266
virtual memory          (kbytes, -v) unlimited

Now I have to find why there exists 2 means of checking/setting limits....

Okay - seems like ulimit and sysctl give a false-positive sense that they actually do something - but instead they seem to be useless. Could someone verify that?

Okay, I'm beginning to understand. As of v10.4, there is no init process anymore, it has been replaced by launchd, which also runs with a PID of 1.

% ps -fu root
  UID   PID  PPID   C     STIME TTY           TIME CMD
    0     1     0   0   0:30.72 ??         0:46.72 /sbin/launchd

And of course worth mentioning is that ulimit is a shell built-in, launchctl is a shell-independent program.

share|improve this answer

My experience is that my high-process-count task only succeeded with:

kern.maxproc=2500 #this is as big as I could set it


ulimit -u 2048

The first two can go into /etc/sysctl.conf and the ulimit value into launchd.conf, for reliable setting.

Since tcp/ip was part of what I was doing, I also needed to bump-up


from its default 128.

Before I increased the process limits, I was getting "fork" failures, not enough resources. Before I increased kern.ipc.somaxconn, I was getting "broken pipe" errors.

This was while running a fair number (500-4000) of detached processes on my monster Mac, OS 10.5.7, then 10.5.8, now 10.6.1. Under Linux on my bosses' computer it just worked.

I thought the number of processes would be closer to 1000 but it seems that every process I started included its own copy of the shell in addition to the actual item doing the actual work. Very festive.

I wrote a display toy that went something like:


while[ 1 ]


n=netstat -an | wc -l

nw=netstat -an | grep WAIT | wc -l

p=ps -ef | wc -l

psh=ps -ef | fgrep sh | wc -l

echo "netstat: $n   wait: $nw      ps: $p   sh: $psh"

sleep 0.5


and watched the maximum number of processes in ps -ef and hanging around in netstat waiting for TIME_WAIT to expire... With the limits raised, I saw 3500+ TIME_WAIT items at peak.

Before I raised the limits I could 'sneak' up on the failure threshold, which started out below 1K but rose to a high value of 1190.. everytime it was pushed into failure it could take a little more next time, probably because of something cached that expanded to its limit every time it failed.

Although my test case had a "wait" as its final statement there were still PLENTY of detached processes hanging around after it exited.

I got most of the info I used from postings on the internet, but not all of it was accurate. Your milage may vary.


share|improve this answer

The following should resolve most solutions (and are listed in order of their hierarchy):

echo 'kern.maxfiles=20480' | sudo tee -a /etc/sysctl.conf
echo -e 'limit maxfiles 8192 20480\nlimit maxproc 1000 2000' | sudo tee -a /etc/launchd.conf
echo 'ulimit -n 4096' | sudo tee -a /etc/profile


  1. You will need to restart for these changes to take effect.
  2. AFAIK you can no longer set limits to 'unlimited' under OS X
  3. launchctl maxfiles are bounded by sysctl maxfiles, and therefore cannot exceed them
  4. sysctl seems to inherit kern.maxfilesperproc from launchctl maxfiles
  5. ulimit seems to inherit it's 'open files' value from launchctl by default
  6. you can set a custom ulimit within /etc/profile, or ~/.profile ; while this isn't required I've provided an example
  7. Be cautious when setting any of these values to a very high number when compared with their default - the features exist stability/security. I've taken these example numbers that I believe to be reasonable, written on other websites.
  8. When launchctl limits are lower than the sysctl ones, there have been reports that the relevent sysctl ones will be bumped up automatically to meet the requirements.
share|improve this answer

On OS X, if you are trying to modify the soft limits for a daemon or process or task, the right way to change these soft limits is not by changing the default launchd config for all processes, but by setting it for the process you are trying to run.

This is accomplished in your launchd .plist file for your process.

If you have a daemon or process running that you need to have more open files for, create a plist file for it and add these params to it:


An example, using mongodb. I create a .plist file called org.mongo.mongodb.plist, and save it to /Library/LaunchDaemons/org.mongo.mongodb.plist. The file looks like this:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "">
<plist version="1.0">

Now your process has the resources it needs, without mucking with the global configuration for the system. This will automatically be set up on restart. Or, if you don't want to restart, you can run

sudo launchctl load /Library/LaunchDaemons/org.mongod.plist

If your process or task is more of an agent than a daemon, you can put the .plist in /Library/LaunchAgents instead. Different rules apply for how launchd will control your process in either case. LaunchDaemons seems reserved for processes that launchd will try to keep up at all times.

share|improve this answer

as an admin I have tried following sudo echo "limit maxfiles 1024 unlimited" > /etc/launchd.conf

and got -bash: /etc/launchd.conf: Permission denied

If I use sudo command then I should be ale to change launched.conf.

By using following article with the help of limit -n 1024 I am temporarily able to increase the size from 256 to 1024 but as soon as I restarted the server it went back 256

share|improve this answer
You might instead ask a new question as this is already answered fairly well. – bmike Dec 4 '12 at 17:48

Your Answer


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.