Evade the macOS ‘Too Many Open Files’ Error by Pushing the Limits

too many files open

Page 2 – Increasing the Processes Limit

Page 2 – Upping the Ante on Processes

Now we can create a similar file to increase the processes limit. Still in Terminal, type this command:

sudo nano /Library/LaunchDaemons/limit.maxproc.plist

Again, you’ll be in a text editor. Copy and paste this content into the file, the same way you did previously for maxfiles.

<?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.maxproc</string>
 <key>ProgramArguments</key>
 <array>
 <string>launchctl</string>
 <string>limit</string>
 <string>maxproc</string>
 <string>2048</string>
 <string>4096</string>
 </array>
 <key>RunAtLoad</key>
 <true />
 <key>ServiceIPC</key>
 <false />
 </dict>
 </plist>

Press Control-X to save and close the text editor, then you can type exit to leave Terminal.

Finally, reboot your Mac and check the results by issuing the commands we used earlier to check our current limits, the sysctl and ulimit lines. In my case, on a mid–2010 Mac Mini, the maximum processes increased, but not to the limits I configured. Both ulimit -a and sysctl kern.maxfilesperproc revealed a limit of 1064 processes. My assumption is that is the most my Mac can handle, but do let me know if you run into the same limitation.

Use your Mac as normally for a few hours to ensure nothing goes awry. That way, you can quickly reverse your changes by deleting the files we created and rebooting. Once you know everything is working fine, you can re-enable SIP.

Turning SIP Back On

Back to Recovery Mode we go. You need to again restart your Mac, and hold Command-R until the Apple logo appears. When Recovery Mode has loaded, open Terminal and run this command:

csrutil enable

That will turn System Integrity Protection back on.

Keep On Cruising

You can, of course, adjust those limits to whatever you believe might be reasonable. Be cautious not to get overzealous, however. Those limitations are there to protect your operating system from rogue applications that are poorly written and might leak memory like a sieve. You don’t want to go too overboard, or you might find your system slowing to a crawl when it runs out of RAM.

8 thoughts on “Evade the macOS ‘Too Many Open Files’ Error by Pushing the Limits

  • Nice information, but it isn’t necessary to disable and reenable SIP, so you can avoid the multiple reboots, making this a lot less painful. You can create the plist in place by just doing:

    sudo vi /Library/LaunchDaemons/limit.maxfiles.plist

    This will make the file’s owner be root:wheel, as needed. You then invoke launchctl to load the new settings:

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

    You can confirm your hard maxfiles limit, before and after, as you noted:

    sysctl kern.maxfiles

    And you can confirm your soft maxfiles limit, before and after, with:

    launchctl limit maxfiles

  • Bonjour,

    Je possède un macbook de mi-2012, et je n’arrive pas à augmenter le nombre de fichiers.
    Lorsque je copie dans la zone de texte le texte suivant

    <! DOCTYPE plist PUBLIC “- // Apple // DTD PLIST 1.0 // EN” http://www.apple.com/DTDs/PropertyList-1.0.dtd

    Label </ key>
    limit.maxfiles </ string>
    ProgramArguments </ key>

    launchctl </ string>
    limite </ string>
    maxfiles </ string>
    64000 </ string>
    524288 </ string>
    </ Array>
    RunAtLoad </ key>

    ServiceIPC </ key>

    </ Dict>
    </ Plist>

    Quand je sauvegarde, je dois mettre quoi comme nom de sauvegarde?

  • One of the things you missed in this is that changing the limits to increase the number of open files can cause slowdowns without a reboot. Even turning SIP off and on, your dynamic reallocation of the uproc (user process; see the ps command) and file tables will cause a remapping of kernel memory. In the case of the Mach microkernel, the SIP process will have to reorganize and relink driver entry points in order to maintain the open file list.

    It is always better to decrease the number of open files than increase them. However, if you are running into open file limits, I would highly recommend that you avoid getting caught by reducing the number of open files… or figure out who is opening more files than necessary, such as a program that is opening multiple sockets to a single server. If you are the developer, you may want to consider a better implementation or, if you are using web-based services, might want to consider setting Keep-Alive to true and reusing the same open connection!

      1. However, there is a way to accomplish this without messing with SIP or rebooting, so I wonder how much of an issue this will be in that case.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.