Apache PHP/OSX Mavericks: - failed to open stream:

Question

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:

1. PHP was upgraded from 5.2.x which bundled with OSX Lion to 5.4.x.
2. I had to get a Zend Debugger for PHP 5.4 by installing Zend Server, picking up the ZendDebugger.so and uninstalling the Zend Server (all this because Zend doesn't provide a standalone version of their debugger for php 5.4.x).

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:

1. Restarting apache helps for a bit, till the error is encountered again.
2. Leaving the web server idle for a bit (no definite interval) also helps.

Answer 1

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.

Answer 2

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.

Answer 3

Got the same error with running xDebug. An upgrade solved the issue.

see:

https://superuser.com/questions/787888/too-many-files-open-on-mac-osx-after-running-apache-in-php-with-xdebug-for-som/829413#829413

Answer 4

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.

Answer 5

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.

Answer 6

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.