Reputation: 11447
I've recently upgraded to OSX Mavericks and since then, I've started getting the aforementioned error on my development machine. There is no obvious problem in the code (it's an auto generated Yii sample application). What has happened as part of upgrade to Mavericks is:
Ever since, I'm getting this problem after maybe loading and reloading the website a few time. After this error occurs, my web server keeps returning the same error for any other application hosted on localhost. I have to mention that static web pages are served up fine.
I've seen several threads on this topic. Most point out to issues in code where file handles are not being closed properly, thereby crossing the open file limit threshold. I also found this thread which seems to suggest this might be a zend debugger issue. There's also a bug report filed for php 5.2.x. Following the thread here, I tried the following:
$ ulimit -a
which reports:
open files (-n) 256
Also,
sysctl -a | grep files
returns,
kern.maxfiles = 12288
kern.maxfilesperproc = 10240
kern.maxfiles: 12288
kern.maxfilesperproc: 10240
kern.num_files: 3248
Another interesting thread suggests to raise this limit (currently 256) using:
ulimit -n 1024
I've tried everything, but nothing seems to be working. The problem is also not consistently reproducible.
I am wondering is using ulimit -n 1024
is going to affect apache, since from what I've read, it affects the number of files shell can have open.
Any help is appreciated.
EDIT:
apache
helps for a bit, till the error is encountered again.Upvotes: 22
Views: 20869
Reputation: 31
I was running into the same issue on El Capitain. Found an article here I owes due credit for the solution. Follow the actions below:
Adjusting Open File Limits To adjust open files limits on a system-wide basis on Yosemite and above, you need to 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>65536</string>
<string>65536</string>
</array>
<key>RunAtLoad</key>
<true/>
<key>ServiceIPC</key>
<false/>
</dict>
</plist>
This will set the open files limit to 65536. 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–. Restart the system.
Also its recommended setting them for the user session in .bashrc and add:
ulimit -n 65536
ulimit -u 2048
Hope this helps.
Upvotes: 2
Reputation: 7891
If you are experiencing this issue while running Apache you can configure apache to increase the limit:
$ sudo vi /usr/sbin/apachectl
locate:
ULIMIT_MAX_FILES=""
and change this line to something like:
ULIMIT_MAX_FILES="ulimit 4096"
Then:
sudo apachectl restart
This will not work for CLI scripts. But adding a ulimit directly to your ~/.bash_profile
(or equivalent) should work for that purpose.
This has the advantage of setting specific limits for apache and your terminal without affecting other apps.
Also, you should be able to adapt this method to other OSs by substituting ulimit
with the command applicable to that environment.
Upvotes: 5
Reputation: 1235
Got the same error with running xDebug. An upgrade solved the issue.
see:
Upvotes: 0
Reputation: 9380
Per http://forums.zend.com/viewtopic.php?t=110823&start=10#p219438 I think this was really just a bug in Zend Server that was fixed in 6.2.
Upvotes: 0
Reputation: 33
Regarding the debugger patch answer above. Unfortunately the answer provided above won't work for me, as it applies to php versions 5.4 and I must limit myself to php 5.3.
Zend has released version 6.3 of their server, which supports php at 5.3. I have been playing with the installation for a little while (after dropping my ulimit back down to Apple's default) to test it and am not experiencing any problems. Before the upgrade I could not do any php debugging without raising that limit.
Upvotes: 0
Reputation: 11447
I was probably suffering from information overload. A possible explanation is offered here which I've also mentioned in my original post. I guess I missed the little detail where the OP mentions that he's working on Mac OSX 10.8.x. I'm on 10.9 so I downloaded the zenddebugger.so from the page and things are looking good. Haven't gotten a single too many open files
all day.
So, perhaps it was a ZendDebugger issue.
Upvotes: 1
Reputation: 2320
Shamelessly stolen from http://docs.basho.com/riak/latest/ops/tuning/open-files-limit/#Mac-OS-X
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 the maximum open file limits in OS X 10.7 (Lion) or newer, edit /etc/launchd.conf and increase the limits for both values as appropriate.
For example, to set the soft limit to 16384 files, and the hard limit to 32768 files, perform the following steps:
Verify current limits:
$ launchctl limit
cpu unlimited unlimited
filesize unlimited unlimited
data unlimited unlimited
stack 8388608 67104768
core 0 unlimited
rss unlimited unlimited
memlock unlimited unlimited
maxproc 709 1064
maxfiles 10240 10240
Edit (or create) /etc/launchd.conf and increase the limits. Add lines that look like the following (using values appropriate to your environment):
limit maxfiles 16384 32768
Save the file, and restart the system for the new limits to take effect. After restarting, verify the new limits with the launchctl limit command:
$ launchctl limit
cpu unlimited unlimited
filesize unlimited unlimited
data unlimited unlimited
stack 8388608 67104768
core 0 unlimited
rss unlimited unlimited
memlock unlimited unlimited
maxproc 709 1064
maxfiles 16384 32768
Upvotes: 19