No Longer Able to Increase Maxfile Limits MacOS Recent Versions

Changing a system-wide setting to work around an issue with a specific product seems rather extreme. A better option would be to change it for that process specifically. If you have access to the code, add a call to setrlimit. If you don’t have access to the code, you could work out how the code is launched and add a wrapper, using either a shell script (and hence ulimit) or a native executable (setrlimit again).

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Vite isn't the only tool affected.

Maven also fails on any moderately sized project as well since any non-trivial project can require more than 256 open files for compilation.

Is there another solution that can be applied systemwide instead of writing wrappers for each tool I notice that is broken after 13.5?

back soon

Is there another solution that can be applied systemwide … ?

There is no direct replacement for the previous launchctl mechanism. The fact that this was placed behind a SIP barrier indicates that this is not accidental.

IMO there are three paths forward:

• If you hit this limit running programs from a shell, use ulimit to change the settings in your shell. You can do this either interactively or in your profile.

• If you hit this with a GUI app, I recommend that you discuss this with the app’s vendor.

• If you hit this with some sort of Unix-y daemon or agent, you can tweak the settings in its launchd property list. You might also want to raise this with the program’s vendor, because having a configuration option for this would make sense.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

I wonder what the appropriate action is, for something like IntelliJ IDEA. The limit has to be changed for IntelliJ itself, Maven, npm. Probably need to change the limit for whatever compiler is used (java, javascript...)

For IntelliJ you can set the maxFile limit at process level from the terminal and then run IntelliJ IDE from that Shell Commands to increase the limit at process level ulimit -Sn 524288 ulimit -Hn 10485760 Then run this command to the IDE /Applications/Intellij\ IDEA.app/Contents/MacOS/idea

Run go mod vendor got "too many open files in system", providing I have deliberately set the maxFiles size to a very high value: 41943040, reboot and not running vscode.

This is in fact a bug. Good news is, there’s a workaround!

launchctl limit maxfiles 256 unlimited
launchctl limit maxfiles 128000 524288

How can this change be made to persist macOS restarts?

Nothing above worked for me so far. I was able change the limit using workaround

launchctl limit maxfiles 256 unlimited
launchctl limit maxfiles 128000 524288

and than fire my IntelliJ from that shell, and I still get the same error.

Only thing that works for me

• boot into recovery mode - shut down the computer, press power button and keep holding it until Options appear, select Options, Continue
• Select drive and login
• open Terminal from menu and run: csrutil clear
• shutdown and return to the recovery mode like before
• open Terminal from menu and run: csrutil disable
• restart (into normal mode)
• create /Library/LaunchDaemons/limit.maxfiles.plist
• restart again

Here's what should be in limit.maxfiles.plist:

<?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>128000</string>
          <string>524288</string>
        </array>
      <key>RunAtLoad</key>
        <true/>
      <key>ServiceIPC</key>
        <false/>
    </dict>
  </plist>

After disabling security policy, I can not run iOS applications, which is quite an inconvenience for me. Still looking for a workaround...

I can confirm problem still exists in macOS 14.0 (23A344)

Not really a solution but a workaround for any Java/JVM based application. -XX:-MaxFDLimit

We used the workaround communicated here with the 13.5 update. However, with 14.1 this no longer works an SIP is preventing anything to change that. Our IDEs and our JVM based app has thousands of jar files in the classpath so it's easy to **** the limit.

But the defaults in 14.1 seem to be actually ok:

❯ ulimit -Sn && ulimit -Hn && launchctl limit maxfiles
unlimited
unlimited
	maxfiles    unlimited      unlimited      

(Can someone please confirm these are the defaults in 14.1?)

The problem seems to be in the JVM and the documentation setrlimit(2).

When passing -XX:-MaxFDLimit to the JVM (whether it's Eclipse, IntelliJ or our own application) we no longer run into any too many open files issues.

The problem seems to be this little code snippet:

#ifdef __APPLE__
      // Darwin returns RLIM_INFINITY for rlim_max, but fails with EINVAL if
      // you attempt to use RLIM_INFINITY. As per setrlimit(2), OPEN_MAX must
      // be used instead
      nbr_files.rlim_cur = MIN(OPEN_MAX, nbr_files.rlim_cur);
#endif

It's following the advice from setrlimit(2) but I'd argue it's a bad advise in our case. Instead I believe the code should check whether nbr_files.rlim_cur == RLIM_INFINITY and not attempt to call setrlimit at all. The process seems to have enough.

Thus, instructing the JVM to not do anything with process file limits (-XX:-MaxFDLimit) solves our "too many open files" problems in Java applications.

I'm on Sonoma 14.0 and I'm also getting Could not set resource limits: 150: Operation not permitted while System Integrity Protection is engaged. I'd love to be able to change the limits, as they are still 256 / unlimited.

It would have been really helpful, @eskimo , if you would have just given a practical example.

Being visually impaired, my greatest pet peeve of all is lack of good documentation in almost everything tech these days. And companies like Apple, with unlimited cash to hire good tech writers, have no excuse.

Because, of course, on macOS, man ulimit does not help (it just spits out the General Commands Manual).

Not helpful.

Here is an actual manual page for ulimit (because Apple doesn't provide it, because, well, it's using an old version of FreeBSD, so who knows how compatible the other flags are): https://ss64.com/bash/ulimit.html

And here is the flag to increase number of open file descriptors:

   -n   The maximum number of open file descriptors. 

For example, before ulimit:

pgbench -c 1000 -T 60 -p 6432
pgbench: error: need at least 1003 open files, but system limit is 256
pgbench: hint: Reduce number of clients, or use limit/ulimit to increase the system limit.

OK, well, how? "...use ulimit..." great, thanks. Note the manual page has at least 24 argument flags!!!

Increase limit for current Terminal session:

ulimit -n 1004

Where 1004 is however many you need, may have to experiment.

(Now how hard was that one-liner to document here? But when we all have to look it up, add up all those hours. Multiply that by 100 times per day for each of us.)

pgbench -c 1000 -T 60 -p 6432

Now works.