#38628: apache2: apachectl script attempts to run ulimit and fails ----------------------+-------------------------- Reporter: cmc@… | Owner: ryandesign@… Type: defect | Status: closed Priority: Normal | Milestone: Component: ports | Version: 2.1.3 Resolution: invalid | Keywords: Port: apache2 | ----------------------+-------------------------- Changes (by ryandesign@…): * status: new => closed * resolution: => invalid Comment: 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 [http://packages.macports.org/apache2/ 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 [http://excid3.com/blog/usrsbinapachectl-line-82-ulimit-open-files-cannot- modify-limit-invalid-argument/ 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. -- Ticket URL: <https://trac.macports.org/ticket/38628#comment:3> MacPorts <http://www.macports.org/> Ports system for OS X