apache2: apachectl script attempts to run ulimit and fails

[cmconnelly (Claire Connelly)]

The apachectl script included with apache2 2.2.4_0 includes a line that attempts to set the ulimit for the server. The arguments are not correct for Mac OS X, and thus fail:

$ sudo /opt/local/apache2/bin/apachectl restart   
/opt/local/apache2/bin/apachectl: line 70: ulimit: open files: cannot modify limit: Invalid argument

The script sets ULIMIT_MAX_FILES to "ulimit -S -n `ulimit -H -n`". Dropping the -n from the soft-limit setting command allows it to work. Apple's apachectl (in /usr/sbin/apachectl) simply defines ULIMIT_MAX_FILES as nothing (""), which also works fine.

[ryandesign (Ryan Carsten Schmidt)]

I don't see this, and you mentioned apache2 "2.2.4_0" which is old; the current version of the port is 2.2.24_0.

[cmconnelly (Claire Connelly)]

Sorry; that was a typo; it's the latest apache2 package.

After removing apache2 (and everything depending on it), and reinstalling, it looks like the apachectl script is fine. Bizarre, but we can close this bug; sorry for the trouble.

[ryandesign (Ryan Carsten Schmidt)]

Glad you got it working.

It looks like Apache decides at configure time how to set ULIMIT_MAX_FILES, using this block on most operating systems:

        if TMP_ULIMIT=`ulimit -H -n` && ulimit -S -n $TMP_ULIMIT ; then
            APACHECTL_ULIMIT="ulimit -S -n \`ulimit -H -n\`"
        else
            APACHECTL_ULIMIT=""
        fi

Which basically says if ulimit -S -n `ulimit -H -n` doesn't return an error, use that, else use nothing. I checked the pre-compiled binaries on ​packages.macports.org and they're all fine; they all use an empty ULIMIT_MAX_FILES. Presumably, when you compiled Apache on your system, this ulimit command did not return an error, but now it does (and on OS X it's supposed to return an error). Could you have had a nonstandard version of the ulimit command on your system at the time that you last installed Apache?

Interestingly, there was a bug in OS X 10.6.5 where ​Apple's included /usr/bin/apachectl had ULIMIT_MAX_FILES set to "ulimit -S -n `ulimit -H -n`", so there is precedent for this being detected incorrectly, but I still don't understand how.