Re: Killing oversized Perl processes

Thanks Perrin

Unfortunately, this doesn't work.
First, failure of a mod_perl process with "Out of Memory!", as occurs 
when the softlimit of RLIMIT_AS is exceeded, does not trigger an Apache
ErrorDocument 500. A mod_perl process that exits (actually CORE::exit() 
must be called), that doesn't trigger an ErrorDocument 500 either.

Second, if Apache detects a server error and redirects to a script, that 
script runs in a new process and has no access to the request object $r. 
It can access the REDIRECT environment variables as discussed in Custom 
Error Response <http://httpd.apache.org/docs/2.0/custom-error.html> .

At this point I think that the best thing to do is use 
 MaxRequestsPerChild 
<http://httpd.apache.org/docs/2.0/mod/mpm_common.html#maxrequestsperchild> 
and Apache2::SizeLimit 
<http://search.cpan.org/%7Egozer/mod_perl-2.0.4/docs/api/Apache2/SizeLimit.pod> 
to handle most memory problems, and simply processes that blow up die 
without feedback to users. Not ideal, but they should be extremely rare 
events.

BR
A

Perrin Harkins wrote:
> On Sun, Mar 14, 2010 at 11:22 AM, Arthur Goldberg <[email protected]> wrote:
>   
>> Perhaps you're referring to Apache's ErrorDocument (also described in Custom
>> Error Response).
>>     
>
> Yes, that's what I meant.
>
>   
>> While that can run local Perl (in a new process of course)
>> as in the example
>>        ErrorDocument 500 /cgi-bin/crash-recover.pl
>> it isn't clear to me how to access $r (which I assume means the Request).
>>     
>
> You can send it to any URL you like, including one handled by mod_perl.
>
> - Perrin
>
>   

-- 
Arthur P. Goldberg, PhD

Research Scientist in Bioinformatics
Plant Systems Biology Laboratory
www.virtualplant.org

Visiting Academic
Computer Science Department
Courant Institute of Mathematical Sciences www.cs.nyu.edu/artg

[email protected]
New York University
100 Washington Sq East
8th Floor Silver Building