Naik, Roshan wrote:
-----Original Message-----
From: R�diger Pl�m [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 12, 2004 2:45 PM
To: [EMAIL PROTECTED]
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
