23377 Views 1 2 Previous Next 21 Replies Latest reply: Jun 26, 2008 6:31 PM by Dean Huxley Go to original post
Just following up my previous posts and the solution we found to work with the 'Too Many Open Files' error, maybe it will help others as well.
The problem seems to be in the way Apple has changed the files/proc settings for Leopard. Using the 'ulimit' and 'sysctl' options to adjust the settings no longer works.
The option you have to use is the 'launchctl limit' command, which also adjusts both the 'ulimit' and the 'sysctl' settings automatically.
To check your existing settings, you can use the command 'launchctl limit', this shows that the server is ridiculously set at a very low maxfiles of 256 files per user/process.
Three columns will be returned, the first column displayed will be the name of the limit setting, you are looking for the 'maxproc' and/or 'maxfiles' settings towards the bottom of the list.
To increase the maxfiles you can use the command 'launchctl limit maxfiles [user max] [system max]', where [user max] is the maximum files you want to allow for each user/process and likewise for [system max].
An example would be (running as super user): launchctl limit maxfiles 2048 unlimited
We first increased this to 2048 unlimited as Apple states in the manual that the Server Admin app is supposed to change the soft process limit from 100 (the default) to 2048 when starting Apache, obviously this is not happening and the default is set to 256, so the manual is out of date or wrong. We did however still find infrequent 'too many open files' errors in apache logs so again increased the limit, this time to 4096 unlimited and have not had a problem since.
The same applies to the maxproc setting if you need additional processes.
You can verify the changes by using the 'ulimit -a' and/or 'sysctl -a | grep files' commands.
To make the changes stick through a restart, you need to add a file (as it doesn't exist) by using something like 'sudo pico /etc/launchd.conf' and add the changes one per line, so in our case, our file looks like this:
limit maxfiles 4096 unlimited
Remember you do not need to add 'launchctl' in front of the commands in this file.
Hope this helps others with this problem, we have not upgraded to 10.5.3 yet, now that things are working in 10.5.2 we will have to setup a test environment before applying anymore potential fuel to the fire!
@Paul Vail: To make the changes stick through a restart, you need to add a file (as it doesn't exist) by using something like 'sudo pico /etc/launchd.conf' and add the changes one per line...
It resides in /etc directory and Apache doesn't load it or need any adjustments as it is a system limitation causing the problem and once you've made the change/s Apache can run free like the wind
Using /etc/launchd.conf to change launchd limits will change things for all processes, which some might consider overkill. For those who just want to raise the limit for a single service started by launchd, try modifying the launchd plist file (eg. /System/Library/LaunchDaemon/org.apache.httpd.plist) to set the soft and hard limits. The com.apple.metadata.mds.plist gives an example of how to increase the NumberOfFiles limit to 1024.
Thanks for the tip Dean Huxley There is a typo in the location of your post, it should be /System/Library/LaunchDaemonS/org.apache.httpd.plist (there is an 's' on the end of LaunchDaemons).
The only concern we have with this solution is that files in /System/Library/LaunchDaemons are installed by Apple and can/will be overwritten on updates/upgrades?
Is there another solution to avoid this happening and only raise the limits for a single service?
Well, in theory, you might be able to copy the plist file to /Library/LaunchDaemons and disable the System one, but I suspect you wouldn't be able to use serveradmin to start and stop apache, etc. (I haven't tried it).
I really don't find it that hard to overwrite/patch the plist file after an upgrade. It probably wouldn't be too hard to write a script to do it. I normally just do a 'diff -r' with the LaunchDaemons directory compared against a time machine backup to see if anything changed after an update, then I put in my own changes if needed.