Which command controls the open file limits?

Which command / configuration file controls the open file limits on OS X? Is there a different command for OS X 10.5 / 10.6 / 10.7? The options I explore below are ulimit, sysctl, and launchctl

"Too many open files" is apparently a common error on Leopard, perhaps other versions of OS X:

• 420 Too Many Open Files

• How to properly increase ulimit -n on Lion?

• Where are the default ulimits specified on OS X (10.5)?

There are many (related?) ways to view the open file limits:

$ ulimit -a
core file size          (blocks, -c) 0
data seg size           (kbytes, -d) unlimited
file size               (blocks, -f) unlimited
max locked memory       (kbytes, -l) unlimited
max memory size         (kbytes, -m) unlimited
open files                      (-n) 2048
pipe size            (512 bytes, -p) 1
stack size              (kbytes, -s) 8192
cpu time               (seconds, -t) unlimited
max user processes              (-u) 512
virtual memory          (kbytes, -v) unlimited


$ launchctl limit
cpu         unlimited      unlimited      
filesize    unlimited      unlimited      
data        unlimited      unlimited      
stack       8388608        67104768       
core        0              unlimited      
rss         unlimited      unlimited      
memlock     unlimited      unlimited      
maxproc     1024           2048           
maxfiles    2048           4096       

$ sysctl -a | grep files
kern.maxfiles = 32768
kern.maxfilesperproc = 16384
kern.maxfiles: 32768
kern.maxfilesperproc: 16384
kern.num_files: 2049

It has been claimed in some of the above posts that these can be modified with the following commands:

sudo launchctl limit maxfiles 16384 32768
sudo ulimit -n 32768
sudo sysctl -w kern.maxfilesperproc=16384
sudo sysctl -w kern.maxfiles=32768

However, out of the above commands, only the sysctl commands have any apparently effect (i.e. ulimit -n and launchctl limit show no change after the above commands have been entered, while sysctl -a does show the requested changes).

The corresponding locations to change these parameters for the OS are:

/etc/sysctl.conf
/etc/launchd.conf

I also discovered one answer which reads that ulimit only controls the current shell.

How can I adjust upwards the max files / max open files limits on macOS?

Solution 1:

The simple answer used to be that there were multiple limits and the lowest limit that you reach in a specific instance will generate your error. Now on 10.12 launchctl limit maxfiles is also in the mix. For details on implementation, this great answer is getting bounty and deserves more votes than the one I can give it.

other relevant threads are:

• `ulimit -n` for non-root
• Why won't kern.maxfiles setting in /etc/sysctl.conf stick?

The ulimit level is set low to prevent one poor shell script from flooding the kernel with open files.

The kern.maxfilesperproc is there to leave a little room in the max files count so that one process can use most but not all of the open file handler space from the kernel.

For normal situations, the kern.maxfiles is the final limiting factor.

On Sierra - the limits are 256 open files and unlimited max, so I'm finding that having 3 to 4 thousand files set for the soft limit works for just about all our hardware and still keeps the system responsive when a runaway process opens too many files. We do like to keep our development servers at the 256 limit so that we catch leaky and problematic software in development / staging and test rather than finding out about it in production.

• http://krypted.com/mac-os-x/maximum-files-in-mac-os-x/

I'm not a fan of 10k files - maybe with APFS and NVMe storage we will see the day when that's not unthinkable, but try to stick with hundreds or low thousands for your file limits. Especially if your mac has a low process limit, having so many files opened by so few processes can be problematic.

Solution 2:

It seems like there is an entirely different method for changing the open files limit for each version of OS X.

For OS X Sierra (10.12.X) you need to:

1. In Library/LaunchDaemons create a file named limit.maxfiles.plist and paste the following in (feel free to change the two numbers (which are the soft and hard limits, respectively):

<?xml version="1.0" encoding="UTF-8"?>  
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN"  
        "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">  
  <dict>
    <key>Label</key>
    <string>limit.maxfiles</string>
    <key>ProgramArguments</key>
    <array>
      <string>launchctl</string>
      <string>limit</string>
      <string>maxfiles</string>
      <string>64000</string>
      <string>524288</string>
    </array>
    <key>RunAtLoad</key>
    <true/>
    <key>ServiceIPC</key>
    <false/>
  </dict>
</plist> 

2. Change the owner of your new file:

sudo chown root:wheel /Library/LaunchDaemons/limit.maxfiles.plist

3. Load these new settings:

sudo launchctl load -w /Library/LaunchDaemons/limit.maxfiles.plist

4. Finally, check that the limits are correct:

launchctl limit maxfiles

Solution 3:

The following should resolve most common problems (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

Notes:

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.