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 Mon, 01 Nov 2004 12:19:35 GMT


Naik, Roshan wrote:
>>If I look at your patch at the end of the mail you would like 
>>to exit the process once the handler has been run. I see the 
>>following problems with that approach:
>>
>>1. exit(0): This does exactly what you do not like: A 
>>function deeper down
>>    in the call stack terminates the process. Furthermore 
>>shared resources
>>    may no get freed correctly. But this may be fixable by 
>>doing it in the same
>>    way Apache processes handle SIGTERM, SIGHUP and similar 
>>signals. So I do
>>    not see a real big problem here.
> 
> 
> 
> Right on! Which is why I call this "band-aid".
> Unfortunately, the way Apache stands today, this idiom is not 
> being followed, and I lack the ambition to fix that.

I do not think that Apache is that bad in this way. A quick review
of the signal handlers showed that most times they only set flags
which lets the currently running code leave loops, functions, etc and
thus get up the call stack.

[..cut..]


> 
> Your (legitimate) concern is essentially about the core Apache resouces
> (i.e. ones not 
> belonging to the handler Module, but the MPM and above) and locks that
> (may) need
> to be processed before/after a fork. 
> 
> If you can point out any instances of this then this is 
> definitely a problem. I briefly looked around 
> (prior to proposing the solutions) but couldn't find any.
 >
> Which means that if you were to register pre/post fork handlers
> today in Apache worker thread prior to handing off to a content
> handler, the handlers are most likely going to be empty
> functions. My opinion is ofcourse based on my understanding 
> which may be incomplete/incorrect.
> 
> I gave this some thought and felt that that it is unlikely 
> to be a problem. 
> 
> My thinking in simple terms: Fork occurs inside the content 
> handler module. So any duped rsources that belong the content
> handler are the responsibility of the content handler. That
> leave us with core Apache resouces (i.e. ones not 
> belonging to the handler Module, but to the MPM and above). 
> 
> Since I call an immediate exit() when control returns to
> a "grand child" apache process, we avoid the problem of double
> cleanup on any apache resources. i.e grand child wont try to
> close files or free locks (or shared memory or connections) 
> belonging the real child. So I don't see much need for post fork
> handler. That brings us to pre fork handler. I really don't know of
> any such resources or locks held by Apache that need to be processed
> prior to forking in the worker thread. Does anybody know of any ?
> If there is any we can come up with a pre fork handler that does
> this job.

Ok, then you did far more work than I did. It was a general concern of mine
and if you checked that this not the case it sounds fine. The good point of this
discussion is the question: Does anybody know of any? If not it is very likely
that there aren't any. One risk that remains left: From my experience band-aids
(at least the good ones) remain longer then the time they have been designed for.
So changes to these core resources might lead to problems later. Of course this
is not the fault of the band-aid itself as it used in situations then where it
has not been designed for.

> 
> 
> 
>>3. On some Unix OS'es a fork does not copy all threads of the 
>>original process
>>    for performance reasons. So the forked process is not an 
>>exact copy of the original
>>    process. This may lead to problems with multithreaded MPM's.
> 
> 
> My UNIX box (HP-UX) is exactly that kind of Unix and I am using 
> worker MPM. Could you be more precise about what those problems 
> are ?

This is a general concern (maybe I am to negative :-)). I had
in mind the folliwng things with this concern: After the fork the content
handler may call Apache API functions. On some MPM's these API functions
might expect some special threads which fulfil special tasks in these MPM's
to be available. For example I am not
sure if this is the case in the worker MPM. So what I would like to say:
This simply needs to be checked. If it is not the case it is fine.
As it is band-aid future MPM's should not matter here.

[..cut..]
>
> 
>>But this would require that the "unknowing" 
>>module is made to call this wrapper when it calls fork.
>>On Unix systems I think this is only possible by some ugly 
>>and maybe not portable dynamic linker voodoo. I have no idea 
>>how this can be reached on non Unix platforms.
> 
> 
> 
> Yes.... Which is why this rules out such brave attempts. :)
> I cant think of how to do this on most UNIX platforms either.

Just a quick thought: It might be possible with things like LD_PRELOAD
or maybe with some tricks in the dl library, but I think if it is possible
it is really ugly (my experience is based on Linux and Solaris).

[..cut..]

>>>I feel it is useful to have this band-aid to stop the 
>>>bleeding till we 
>>>take it to the hospital.
>>
>>Sorry, for sounding too sarcastic, simply could not resist:
>>I am not quite sure if the patient will reach the hospital 
>>alive with this band aid ;-).
> 
> 
> :D 
> Another concern is if the patient will ever get any help
> or will he only be shown the prospects of better
> cures. 


Yes, this is true. My concern is that if the bleeding is stopped nobody
will take care of the patient any longer. :-).





Mime
View raw message