Return-Path: Delivered-To: apmail-httpd-dev-archive@httpd.apache.org Received: (qmail 99508 invoked by uid 500); 3 Oct 2002 18:18:34 -0000 Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm Precedence: bulk Reply-To: dev@httpd.apache.org list-help: list-unsubscribe: list-post: Delivered-To: mailing list dev@httpd.apache.org Received: (qmail 99495 invoked from network); 3 Oct 2002 18:18:33 -0000 Subject: Re: RLimitNPROC behaviour question From: =?ISO-8859-1?Q?Andr=E9?= Malo References: <20021003012332.GA20263@rawbyte.com> <3D9C7E52.3040509@slive.ca> Organization: TIMTOWTDI Message-ID: User-Agent: Xnews/5.04.25 To: dev@httpd.apache.org Date: Thu, 03 Oct 2002 20:15:01 +0200 X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N * Joshua Slive wrote: [RLimitNPROC] > I think it still applies: It says that using that directive may limit > the total number of cgi processes that can be launched at one time. And that's not true, as far I can see. The directive works for me as follows: mod_cgi creates a new process via fork. If successful, for the new child process the rlimit stuff will be set. It applies *only* to this child. After that exec will be called to start the external program/script (under circumstances via suexec). If now the CGI-process (means the external program) tries to fork, the system counts the number of current processes of the processes' effective uid and refuses, if the number exceedes the limit (set by RLimitNPROC). That means, RLimitNPROC doesn't apply to the number of launched CGI-processes rather than the number of processes a CGI-program may launch. (more or less that, what the short description says). For example: RLimitNPROC 1 means in practise: a CGI program may send a mail by piping it to /usr/lib/sendmail if there's no concurrent process, i.e. it runs alone. whether that makes sense or not...dependant on system/policies/etc., I think. Side note: If suexec would fork a new process after changing the uid, then RLimitNPROC really would limit the number of CGI processes launched by mod_cgi. I hope, I don't spread nonsense here ;-) nd -- Real programmers confuse Christmas and Halloween because DEC 25 = OCT 31. -- Unknown (found in ssl_engine_mutex.c)