Hi,
Yes, you are right, a httpd process marks a fcgid process as busy and then
suddenly dies would cause the zombie issue.
I agree with your idea except: don't move process to error list, but a new
create process list (like zombie list?). Because a processs busy timeout not
necessary mean the httpd process die, what if the httpd process not die and
then try to modify the process slot which has been apply by the another httpd
process?
This idea has a problem: how to deal with the slots in "zombie list"? these
slots may or may not be using by the httpd processes which apply them. A
reasonable timeout may solve this problem, but any better idea?
>
> on 11/09/2013 09:11 Andriy Gapon said the following:
> > I've been thinking about this problem and the only theory that I have got
> > so far
> > is that perhaps an owner httpd process could terminate ungracefully (e.g.
> > crash). In that case the pool cleanup would never be run. That's OK for
> > process local resources like memory or file descriptors, which would be
> > freed by
> > OS because the process dies anyway. But that's not OK for external
> > resources
> > like other processes.
> > In other words, if an httpd process marks an fcgid process as busy and then
> > suddenly dies, then there is nobody to move the fcgid process back to the
> > idle list.
>
> Just an idea: perhaps scan_busylist should move a process to a different list
> (the error list?) after treating it with proc_kill_force?
> Currently the processes on the busy list are never checked for being a zombie.
> With the proposed change they should be correctly reaped after all the waiting
> and killing.
>
> --
> Andriy Gapon
>
>
