general/3482: The RLimit* directives are bizarre

[Jon Ribbens <jo...@oaktree.co.uk>]

>Number:         3482
>Category:       general
>Synopsis:       The RLimit* directives are bizarre
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    apache
>State:          open
>Class:          sw-bug
>Submitter-Id:   apache
>Arrival-Date:   Wed Dec  2 17:20:01 PST 1998
>Last-Modified:
>Originator:     jon@oaktree.co.uk
>Organization:
apache
>Release:        All
>Environment:
Any
>Description:
The RLimit* directives call setrlimit() in call_exec() which is really strange.
Why would you want to call them there? They should be called in child_main().
I see from PR#783 that someone agrees with me but the patch never got
applied it seems.

My particular gripe is that my server is saying 'failed to spawn child process'
(which is a really unhelpful error message as it doesn't include the errno).
I eventually discovered that this was because of RLIMIT_NPROCS. (Yes, I guessed
this earlier so I put RLimitNPROC in my configuration, but the problem is only
intermittent and it took me a while to figure out that this hadn't fixed it,
and then *why* this hadn't fixed it.)
>How-To-Repeat:

>Fix:
At the very least the documentation needs to be fixed, since at least for
RLimitNPROC it is just plain wrong, and for the others it is very misleading.
But the much preferable alternative is to move the setrlimit calls to
child_main() where they make much more sense. Having a RLIMIT_NPROC for some
processes owned by a user (i.e. CGI scripts) being different for that of other
processes owned by the same user (i.e. httpds) is a really broken situation.)

The other thing mentioned in PR#783 (not being able to decrease the hard limit
if not root) also needs fixing and is trivial, but I don't care about that
personally ;-).
>Audit-Trail:
>Unformatted:
[In order for any reply to be added to the PR database, ]
[you need to include <ap...@Apache.Org> in the Cc line ]
[and leave the subject line UNCHANGED.  This is not done]
[automatically because of the potential for mail loops. ]
[If you do not include this Cc, your reply may be ig-   ]
[nored unless you are responding to an explicit request ]
[from a developer.                                      ]
[Reply only with text; DO NOT SEND ATTACHMENTS!         ]