[MacPorts] #38628: apache2: apachectl script attempts to run ulimit and fails

[MacPorts]

#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