In my humble opinion it is much simpler (and cleaner) to fix this
problem in one place...Apache, rather than in each module that may
face this problem.
> 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.
This is unfortunately not feasible (even though possible). The reason
being that there are so many perl modules out there that are being
widely used by programmers. You cant know which function call can
possibly call a fork(). For example would you ever imagine that Perl's
Syslog module would need to fork ? Well it does... and I was really
surprised too. That's actually where I noticed this whole problem.
Not only does it call fork() but it seems like its unpredictable as
to when it calls fork(). It seems to do so if we pound on it too
much. Prusuing this option requires too much knowledge on part of
Programmers about the internals of the various modules that they
will be using.
>
> 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.
Yes ... and I don't fully understand the scope or the reasoning
behind those. I still think handling it at Apache level is better
than handling it at content handler. That should also simplify
the task of writing modules. As a nice side effect a rogue
(or naïve) module will not be able to hang apache.
>
> Of course mod_perl must do the cleanups by calling the
> appropriate Apache API functions before terminating the process.
I dont think it is good idea for a function deeper down in
the call stack to try to clean up resources allocated by
functions higher up in the call stack. Mod_perl can (and
should have to) only clean up resources that it has allocated.
For now most of these solutions seem to be aspirational and nothing
concrete likely to materialize soon. For now I would like to propose
the solution 2 ( in my original email) as a patch. The idea is to invoke
exit(0) (if we are in the forked worker) just after ap_run_handler is invoked
by ap_invoke_handler....
AP_CORE_DECLARE(int) ap_invoke_handler(request_rec *r)
{
// ...snip....
result = ap_run_handler(r);
if ( I am a forked worker ) {
exit(0); // terminate at the earliest possible stage after request was
processed
}
// ...snip....
}
This solution is a band aid to fix the current shortcoming in design. We
can get rid of this when (if ever) a full fledged solution is worked out.
I feel it is useful to have this band-aid to stop the bleeding till
we take it to the hospital.
-Roshan
