Is there a fix for the "Too many open files in system" error on OS X 10.7.1?

Question

I need to get rid of the pesky "Too many open files in system" limit on OS X 10.7.1.

Is there a way?

Do you want to explain more about when this happens? In which circumstances? — slhck, Jun 07 '12 at 08:56
@slhck - I have the same problem. The circumstances are basically "at random." I'm a developer, so I'm using my Mac fairly heavily: running one or more databases, a web server, testing tools, one or more browsers, and a music player all at once. Google Chrome seems to be one program that has a lot of files open. — Nathan Long, Jun 22 '12 at 18:25
Actually, my "heavy use" wasn't the issue; my settings for the maximum number of open files for the kernal and per-process were far lower than what the defaults should be. — Nathan Long, Jun 29 '12 at 20:16
If your read Nathan's comment and wondered why he didn't include any details about the defaults, it's because he spelled it all out in his answer, below. (Nice answer! :) — Olie, Jun 13 '13 at 18:06
I'm in the same usage circumstance as Nathan Long, and found restarting Apache was the only step that "solved" the problem. I applied all the below limit increases but they didn't help immediately. I am running command line phpUnit tests > selenium server > firefox > apache > php > mysql all on the same macbook. Used to work fine until I upgraded to mavericks. The error I get is in the webapp being tested, i.e. it's php/apache running out of files, so presumably not controlled by the shell setting. — scipilot, Sep 19 '14 at 07:55
You mentioned you're a developer; regardless of the defaults, this can also happen if a program opens files and leaves the file handles open. Make sure the software you're developing successfully closes each file it opens after it is done with it. — rob, Dec 14 '16 at 18:59
In my case, I closed and reopened Terminal. Problem went away. — Mike S., Dec 27 '18 at 15:10

score 280 · Answer 1 · edited Oct 05 '17 at 12:40

280

According to this helpful article (which I recommend reading):

By default, the maximum number of files that Mac OS X can open is set to 12,288 and the maximum number of files a given process can open is 10,240.

You can check these with:

sysctl kern.maxfiles
sysctl kern.maxfilesperproc

You can increase the limits (at your own risk) with:

sysctl -w kern.maxfiles=20480 (or whatever number you choose)
sysctl -w kern.maxfilesperproc=18000 (or whatever number you choose)

To make the change permanent, use sudo to put your settings in /etc/sysctl.conf (which you may have to create), like this:

kern.maxfiles=20480
kern.maxfilesperproc=18000

^{Note: In OS X 10.10 or lower, you can add setting in /etc/launchd.conf like limit maxfiles and it will override whatever you put here.}

Again, from the article:

Once you’ve done this, the kernel itself will have a maximum number of files but the shell might not. And since most processes that will take up this many files are going to be initiated by the shell you’re gonna want to increase that.

The command for that is:

ulimit -S -n 2048 # or whatever number you choose

That change is also temporary; it only lasts for the current shell session. You can add it to your shell configuration file (.bashrc, .zshrc or whatever) if you want it to run every time you open a shell.

edited Oct 05 '17 at 12:40

kenorb

24,736
27
129
199

answered Jun 29 '12 at 20:23

Nathan Long

26,015
36
102
139

1

what limit applies to processes launched by clicking icons in the launch area? And how to change that limit? When you say "shell", I'm assuming you mean an interactive terminal shell. – Cheeso Aug 15 '12 at 00:48
@Cheeso - I **think** that the overall system limit (sysctl) or the launchd limit, whichever is lower, controls that. – Nathan Long Dec 14 '12 at 20:39
1

creating an /etc/launchd.conf with contents limit maxfiles 1000000 1000000 worked great for me! (OSX 10.8.2 here) – Aaron Silverman Feb 01 '13 at 19:26
1

I put ```kern.maxfiles=65000 kern.maxfilesperproc=65000``` in /etc/sysctl.conf and rebooted. kern.maxfiles was ignored and stayed the default but kern.maxfilesperproc was set to 65000. I have no /etc/launchd.conf so what's up with that? – pferrel Nov 13 '14 at 00:47
Note 10.10.3 changes this max https://twitter.com/hichaelmart/status/586681771485487104 – engineerDave Apr 17 '15 at 15:11
1

I come here to find this post at least once every 6 months or so! Awesome ;) – brandonscript Jul 28 '16 at 01:46
@brandonscript Thanks for saying so. :) Pro tip: I document this kind of stuff online after I figure it out partly so that **I** can Google it more easily next time I have the problem. Do likewise and maybe I'll find your answer to my next question. – Nathan Long Jul 28 '16 at 12:57
Heh I've got a handful of those on that _other_ Stack Exchange site :) – brandonscript Jul 28 '16 at 14:05
3

If anyone has problems with max files not sticking, it is because there is a trailing space after the maxfiles line, that needs to be deleted. – jjathman Oct 14 '16 at 16:27
@jjathman thanks for your comment about the trailing space, had that problem, removing it fixed it for me! – Ricky Nelson Jan 30 '17 at 11:32
Nathan, I do the same (entering solutions when I find them), also put it in a tweet. Should update the answer here noting the reboot into recovery mode needed to unlock sysctl as of 10.10.3 – Tracker1 Jun 01 '17 at 21:36
What's the equivalent for Catalina? – adib Oct 15 '19 at 14:24
This doesn't work on newer versions of Mac, see answer below for For OS X Sierra which works on Ventura 13.3 too. – Hackeron Apr 05 '23 at 12:59

score 82 · Answer 2 · edited May 15 '17 at 23:43

82

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. Create a file at /Library/LaunchDaemons/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

edited May 15 '17 at 23:43

Kyle Falconer

127
7

answered Jan 24 '17 at 14:56

ninjaPixel

1,608
14
9

worked perfectly, thanks! In my case the error manifested in a java process with the message `IO Error: Bad file descriptor (Write failed)` – agradl Mar 22 '17 at 16:52
1

Also works on El Capitan 10.11.6 – Troy Daniels Apr 17 '17 at 17:23
still cannot change the ulimit for shell. The maximum stays 1024 whatever I do – DataGreed Oct 06 '17 at 00:46
At step 2 run: sudo chmod 600 /Library/LaunchDaemons/limit.maxfiles.plist sudo chown root /Library/LaunchDaemons/limit.maxfiles.plist – Hai Nguyen Jun 21 '18 at 08:00
It also works in OSX Big Sur. – Gnought Jul 27 '21 at 06:44
1

Works in MacOS Ventura 13.3 – Hackeron Apr 05 '23 at 12:57

sanmai · Answer 3 · 2020-07-20T00:11:44.890

46

Other option may be finding the culprit:

sudo lsof -n | cut -f1 -d' ' | uniq -c | sort | tail

For the last one you could see what files are open:

sudo lsof -n | grep socketfil

And kill the process if so desired

kill $pid

From the comments:

For what it's worth, you can also get a list of the process IDs with the most open files using
lsof -n +c 0 | sed -E 's/^[^ ]+[ ]+([^ ]+).*$/\1/' | uniq -c | sort | tail

edited Jul 20 '20 at 00:11

answered Feb 18 '17 at 00:42

sanmai

1,162
12
16

Helpful! But sort on OS X (10.11) doesn't take -h. (Maybe -g?) – Robert Calhoun Mar 03 '17 at 14:52
1

For me worked well just without `-h` (OS X 10.12.3): `sudo lsof -n | cut -f1 -d' ' | uniq -c | sort | tail` – vearutop Mar 06 '17 at 03:42
So be it without `-h` – sanmai Mar 06 '17 at 10:27
This is the only answer that helped me to root cause my issue.. thanks :) – SgtPooki Mar 11 '17 at 10:46
For what it's worth, you can also get a list of the process IDs with the most open files using `lsof -n | sed -E 's/^[^ ]+[ ]+([^ ]+).*$/\1/' | uniq -c | sort | tail`. – Chris Frederick May 12 '17 at 04:52
Reeder had 631 open! awacsd had 4297 which was probably the problem. – malhal Jan 22 '18 at 15:54
2

Use `lsof -n +c 0` to prevent truncating process name. – vaughan Jul 12 '18 at 11:45
1

Running Catalina, and I prefer `lsof -n +c 0 | sed -E 's/^([^ ]+[ ]+[^ ]+).*$/\1/' | uniq -c | sort | tail` (ie, move the first open parenthesis further left to include the command name in the output). Gives me this: ``` ... 629 Google\x20Chrome 50163 669 phpstorm 89615 681 Microsoft\x20Outlook 89373 808 vpnkit-bridge 755 1176 zoom.us 1382 ``` Here, zoom, PID 1382, has 1176 open files, the most of any process on my system right now. – Joseph Cheek Jul 19 '20 at 04:16
Here I found out that `ripgrep` was kept open, while I didn't consume the whole buffer, and `ripgrep` itself had llooooottts of open files underneath. `lsof -n` and some `grep` magic helped find the culprit indeed. Thanks! – abourget Feb 10 '22 at 22:08

score 42 · Answer 4 · answered Jun 07 '12 at 11:09

42

You will need to increase your ulimit settings - it's pretty low on OS X these days - 256 by default. Add ulimit -n 4096 or similar to your ~/.profile or equivalent and that will solve it in your local environment. Run ulimit -a to check your current levels

To see the system settings, run this:

launchctl limit maxfiles

It is set quite a bit higher in Lion (10240) on a per process basis than it used to be. But if you are still hitting it there then you can set it higher using the same command with the desired levels. To make the changes permanent /etc/launchd.conf is where you need to add the relevant lines.

answered Jun 07 '12 at 11:09

Adam C

2,735
21
27

2

256? It's 2560 file descriptors for me and I've never changed it. The limit is 266 processes (c.f. `ulimit -a`). – slhck Jun 22 '12 at 18:55
@slhck it says `open files (-n) 256` for me too, not `2560` – May 25 '13 at 10:43
Which version of OS X are you running? – nealmcb May 26 '14 at 18:19
2

Same for me, 256 files on MacOS X Maverick – Climbatize Aug 09 '14 at 06:44
4

256 on OS X Yosemite as well – Alexander May 28 '15 at 09:52
2

256 on El Capitan, too. – TMN Apr 28 '16 at 10:53
1

256 in Yosemite. – Jaec Jun 16 '16 at 22:50
1

256 still on Sierra. – ylluminate Apr 06 '17 at 18:53
ulimit -n 4096 won't work - it still remains 1024 although I don't have this limit anywhere – DataGreed Oct 06 '17 at 00:47
`ulimit -n 4096` did not update the output of `launchctl limit maxfiles` , what should I do ? @Adam C – alper Aug 02 '18 at 20:58
`ulimit` still works on Mojave (10.14.6) too (in order to increase the *shell* maxfiles limit) – Oliboy50 Dec 11 '19 at 08:51
256 on Catalina 10.15.7 – Jon Kern Oct 31 '20 at 15:02
256 on Monterey in 2021 too ;) – cryanbhu Nov 23 '21 at 11:08

score 14 · Answer 5 · answered Sep 04 '14 at 16:19

14

Folks, on Mavericks 10.9.4

ulimit -n 2048 works fine. You may need to launch a new login session.

answered Sep 04 '14 at 16:19

Clustermagnet

409
2
7
12

score 6 · Answer 6 · edited Nov 23 '18 at 17:33

6

For latest macOS (at the time of writing: 10.14.1), you can use sudo launchctl limit maxfiles 64000 524288 (by default it was 256), but it works only within current session. Use launchctl job from @ninjaPixel (https://superuser.com/a/1171028/760235) for permanent solution.

edited Nov 23 '18 at 17:33

Worthwelle

4,538
11
21
32

answered Nov 23 '18 at 16:59

Dzmitry Hubin

161
1
3

1

How did you come up with the number 524288? My previous values were 256 and unlimited. – Chip Roberson Oct 06 '19 at 21:39

angelokh · Answer 7 · 2019-06-08T01:57:34.833

Similar to https://superuser.com/a/1171028/367819

To check the current limits on your Mac OS X system, run:

launchctl limit maxfiles

The last two columns are the soft and hard limits, respectively.

To adjust open files limits on a system-wide basis in Mac OS X Yosemite, you must create two configuration files. The first is a property list (aka plist) file in /Library/LaunchDaemons/limit.maxfiles.plist that contains the following XML configuration:

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

This will set the open files limit to 200000. The second plist configuration file should be stored in /Library/LaunchDaemons/limit.maxproc.plist with the following contents:

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

Both plist files must be owned by root:wheel and have permissions -rw-r--r--. This permissions should be in place by default, but you can ensure that they are in place by running sudo chmod 644 . While the steps explained above will cause system-wide open file limits to be correctly set upon restart, you can apply them manually by running launchctl limit.

In addition to setting these limits at the system level, we recommend setting the at the session level as well by appending the following lines to your bashrc, bashprofile, or analogous file:

ulimit -n 200000
ulimit -u 2048

Like the plist files, your bashrc or similar file should have -rw-r--r-- permissions. At this point, you can restart your computer and enter ulimit -n into your terminal. If your system is configured correctly, you should see that maxfiles has been set to 200000.

You can follow this article for more details.

https://gist.github.com/tombigel/d503800a282fcadbee14b537735d202c

Remember to restart your Mac to have the values effective.

Either the post should be marked as a duplicate if there is already an answer, otherwise, please post the relevant information from a link, as the link may not be valid forever. — zymhan, May 30 '19 at 01:04

score 3 · Answer 8 · answered Jan 25 '19 at 13:15

3

After all changes above my java didn't made more that 10000 files. Solution was this jvm flag -XX:-MaxFDLimit

answered Jan 25 '19 at 13:15

Uros Velickovic

31
1

White space is bad, m'kay? I had a space between -XX: and -MaxFDLimit and it wouldn't work. Thanks – Coder-guy Oct 01 '20 at 14:01

score 2 · Answer 9 · answered Aug 12 '20 at 09:59

Increasing the number of authorized files read and write should never be considered as a good common practice.

As sanmai and many suggested you could simply try to kill some overwhelming processes. Probably the ones involved in the increase of number of file manipulations.

1-/ Step one retrieve the most file consuming processes

lsof -n +c 0 | cut -f1 -d' ' | uniq -c | sort | tail

2-/ Step two use theses names to kill all the processes they are involving. beware of not killing systematically any file consuming process since it might be essential for your current activity.

ps -e -a |grep file-consuming-process |for i in `awk {'print$1'}`; do kill -9 $i; done

repeat the process until you kill the undesired mighty daemons.

Have fun :)

score 1 · Answer 10 · answered May 18 '17 at 02:52

1

You can run

lsof -n

which process open too many files.

then kill it .

or

sysctl -w kern.maxfiles=20480

change it to bigger one.

answered May 18 '17 at 02:52

SaintKnight

11
2

3

Please explain how this answer differs from the ones already given. – Stephen Rauch May 18 '17 at 03:30

score 0 · Answer 11 · answered Dec 14 '16 at 18:50

0

I encountered it while doing a chmod -R so I got it around by taking smaller steps, e.g.

# for each directory
find . -type d -exec chmod 755 {} \;

answered Dec 14 '16 at 18:50

Michael

1

1

While this may be a work-around, it doesn't appear to actually answer the question. Perhaps explaining that you cannot get rid of the message and then proposing this as one way to make it less of an issue would improve your answer. – music2myear Jan 04 '17 at 21:11

score 0 · Answer 12 · answered Mar 24 '20 at 01:34

I had this issue on a 2017 Macbook running Catalina. The issue was Spotify (which was up to date), and the Spotify setting "Show Local Files".

This setting allows Spotify to look through your downloads folder or other folders and for some reason it was opening and checking but not closing the files. Checking lsof -n this was actually over 7500 files including thousands of .jpg files as I had not cleaned out my downloads folder in a long while. Not sure why Spotify didn't close them, seems to be a bug.

Disabling this setting and restarting Spotify may work, alternatively just uninstalling will work.

score 0 · Answer 13 · answered Mar 05 '23 at 16:10

0

For me, most of the suggested answers worked after I have restarted my device and run the mongorestore with internet browsers, Spotify, Slack etc. are closed. I am guessing opening a new terminal shell or turning off the apps does not release the resources immediately.

Therefore, if you are gonna use the mongorestore more than once in the same session, I'd advice to follow my suggestion above.

answered Mar 05 '23 at 16:10

Melih

101
1
4

Avoid posting answers to old questions that already have well received answers unless you have something substantial and new to add. – Toto Mar 05 '23 at 16:25
I think my comment is quite substantial, because the solutions provided were not working on their own for me and this error made me lose couple of days to fix. Also, the question is asked in 2012, received answers 2016, 2017, 2020.. My answer which is in early 2023 is not differentiating in terms of value of the contribution from others in my opinion. – Melih Mar 05 '23 at 20:36

Is there a fix for the "Too many open files in system" error on OS X 10.7.1?

13 Answers13

Linked

Related