Opened 12 years ago

Closed 12 years ago

#38628 closed defect (invalid)

apache2: apachectl script attempts to run ulimit and fails

Reported by: cmconnelly (Claire Connelly) Owned by: ryandesign (Ryan Carsten Schmidt)
Priority: Normal Milestone:
Component: ports Version: 2.1.3
Keywords: Cc:
Port: apache2

Description

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.

Change History (3)

comment:1 Changed 12 years ago by ryandesign (Ryan Carsten Schmidt)

Keywords: apache ulimit apachectl removed
Owner: changed from macports-tickets@… to ryandesign@…
Summary: apachectl script attempts to run ulimit and failsapache2: apachectl script attempts to run ulimit and fails

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.

comment:2 Changed 12 years ago by 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.

comment:3 Changed 12 years ago by ryandesign (Ryan Carsten Schmidt)

Resolution: invalid
Status: newclosed

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.

Note: See TracTickets for help on using tickets.