On Fri, Feb 15, 2002 at 01:50:31AM -0800, Adam Sussman wrote: > This works well with perfork and worker under Linux. I have a couple > of comments though: > > 1) There are some not infrequent cases I have run into where apache > needs to be killed (for unrelated reasons) and the shared memory > segment does not get cleaned up. When this happens, you can't restart > the server. You get a "file exists" error and apache refuses to start > up. This is easy to fix with ipcrm but the error is confusing and > does not make the solution obvious. > > It would be nice if apache would clean up the shared memory segement > if it sees it, or have a more meaningfull error.
The problem here is that there's a way to automatically destroy a segment when all the processes die that had it attached, but as soon as you mark the segment for auto-death no new processes can attach to it. This is obviously a side effect of a larger lingering process problem in apache, but it is still a legitimate problem, IMHO. [To get rid of at least one of those lingering process problems, grab HEAD from CVS.] We could add a new routine to apr_shm.h in APR for preremoving a segment; it could attach to a segment to see if it exists, set it for removal, then detach. Then if the EXCL creation fails then there is another process still running. > 2) Unless I am missing something, there does not seem to be an easy way > for an external application accessing the scoreboard to know how to > navigate the data structure. You have to know the server limit and > thread limit or else you run into problems. It would be nice to > be able to derive those values from the scoreboard image instead of > the httpd.conf file. That may get us into a chicken-and-egg -- IIRC the scoreboard size is proportional to the server limit and thread limit. :) I do agree that we need a better way to access the structure of the scoreboard. -aaron
