httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From r.pl...@t-online.de (Rüdiger Plüm)
Subject Re: Bug: Apache hangs if script invokes fork/waitpid
Date Sun, 17 Oct 2004 00:20:26 GMT


Naik, Roshan wrote:
>  
> 
> 
>>-----Original Message-----
>>From: Rüdiger Plüm [mailto:r.pluem@t-online.de] 
>>Sent: Tuesday, October 12, 2004 2:45 PM
>>To: dev@httpd.apache.org
>>Subject: Re: Bug: Apache hangs if script invokes fork/waitpid
>>
>>[..cut..]
>>
>>I think 1. is the "problem" in our case. If you do a fork in 
>>your perl script you simply create another Apache process 
>>where your forked perl script is running inside. After the 
>>forked part of the script has finished its job mod_perl will 
>>be left and the Apache process will continue doing its normal 
>>"designed" work: Waiting for the next request.
> 
> 
> I would prefer not to call it as "designed to work". It seems
> like this situation was not taken into considertaion in the design.
> Atleast I don't believe it was designed deliberately so that it would 
> hang.

Ok. You are right that for sure it has not been designed to hang. What I mean by
"works as designed" is that the design does not allow user provided code within
Apache to do a fork without proper preparation. I would not say that it was not
taken into consideration. But I think these are more or less philosophical questions
that drive us away from the real problem and a solution for this problem.

[...]

> 
> 
> 
>>This behaviour should be totally independent from the MPM you use.
> 
> 
> Yes, ideally it should. I am not sure if it is the case though.
> 
> 
>>So I think mod_perl needs to provide some kind of wrapper for 
>>the fork command that does the needed cleanups just before 
>>the real fork is done (as other modules in Apache do that 
>>fork processes) and that will terminate the process as soon 
>>as the user provided perl code of this forked process is 
>>left. So the behaviour will differ from the normal mod_perl 
>>behaviour (giving control back to the Apache process / thread).
>>
> 
> 
> It is not a mod_perl specific problem. It is a problem with any module
> like mod_perl. That is a script executed by this module can invoke fork().

You are right that any module trying to do a fork and execute code in the forked
process will experience the same problem, BUT: Modules should not do a fork or allow
code they execute like scripts to do a fork without doing proper pre- and post operations.
If they do, it is either a bug of the module or a bug of the script they execute.
Do not get me wrong: I admit that may be there should be some additional
API functions for a module to prepend a fork and cleanly exit this forked
process afterwards. These API function should be usable for the module without
having a knowledge of the running MPM.

> 
> You see it is not appropriate to handle this situation in mod_perl. For the
> following reasons:
> 
>  - mod_perl doesn't really know that the scipt called mod_perl. It hands off the
>    script to Perl to interpret and execute. So it is Perl who is acutally calling
>    fork()...not mod_perl

This is the real problem: mod_perl does not have real control over what the Perl script
does once it handed it over to Perl. As Perl allows you to do many things, there are many
ways to harm the Apache process used as a container to run the Perl script. So special care
must be taken when writing Perl scripts for mod_perl and if you do not think that the script
writers are trustable then mod_perl should provide some kind of sandbox for executing the
code
to prevent such harmful operations. So from the part of the Perl script I see only two approaches:

1. Guidelines for script programmers that clearly state that you have to call a special
    Perl function for doing a fork inside mod_perl, because otherwise you will shoot yourself.

2. Create some kind of sandbox for the code running inside mod_perl to prevent the code doing
    harmful things like fork in our case. This may be also useful for other applications to
    restrict the permissions of a script.

mod_perl on the other side should provide a function that allows the Perl script running
inside mod_perl to do a fork in a safe way. Therefore it must embed the real fork library
/ system
call into the correct pre and post operational code. Whether this pre and post operational
code
should receive better support from Apache API functions should be part of the further discussion.
As far as I remeber possible approaches like a special mod_fork have already been discussed
by Jeff and Paul in this thread.


> 
>  - This means mod_perl needs to know too much about the Apache's internal working. 
>    As to whether it should call pthread_exit() or exit() is dependent on the MPM.

As said above this should be encapsulated in appropriate API functions that do not
require the caller to have any knowledge of the MPM running.

> 
>  - Secondly mod_perl's decision to terminate could be premature.... it doesn't give 
>    apache any chance to perform any clean ups and other things(if needed).

Of course mod_perl must do the cleanups by calling the appropriate Apache API functions before
terminating the process.

[...]

Regards

Rüdiger


Mime
View raw message