On Tue, Nov 12, 2013 at 1:16 PM, William A. Rowe Jr. <wr...@rowe-clan.net> wrote: > On Tue, 12 Nov 2013 09:04:13 -0500 > Eric Covener <cove...@gmail.com> wrote: > >> On Mon, Nov 11, 2013 at 7:30 AM, Ruediger Pluem <rpl...@apache.org> >> wrote: >> > >> > >> > Eric Covener wrote: >> >> I was looking at a typical apr_thread_create failure for creating a >> >> large # of threads on a system, and the only solution was to >> >> increase roots RLIMIT_NPROC as opposed to the (httpd.conf >> >> configured) "User" limits >> > >> > I assume that you configured that via /etc/security/limits.conf? >> >> Yep. I still haven't figured out if the target users ulimits ever >> matter (around setuid() call, as implied by the manual) or if it's >> 100% root. > > So to further clarify, your understanding right now is that... > > - root's soft ulimit overriden by any ulimit -u in the startup > script is honored for the parent httpd process
yes > > - ulimit is not replaced with User's limits during startup/setuid > by the time we're creating worker threads, roots ulimit still matters, which is consistent with fork() doc > - the User's hard ulimit is checked and causes the startup to fail > if the (root) soft ulimit then exceeds the user's max hard limit? Not following on this one. My guess is that the Users limit will be checked at setuid(), where we'll be adding one more thread. At this point, you'd have to think any existing worker threads count against the Users limit (even though when they were being spawned, roots ulimit was the operative one). I have not been able to return to testing it, was hoping someone already had it collected as a FAQ.
