On 2009-07-10 03:19:47 PM, Graham Dumpleton wrote: > Normally assert() would see details of the assertion being written to > stderr. Under Apache though, because of stderr being buffered, that > information may not be shown in Apache error logs if inside assert() > it is not explicitly flushing stderr after writing any information. In > other words, the details of the assertion may be getting lost. This > may not be the case though, and suggest you have a good look through > the error logs, including the main Apache error log if this is > actually for a virtual host with its own error log, for any line which > doesn't have the leading date/time stamp on it. Hi, I looked a little bit up from the log snippet that Mike posted, and indeed, there was a line:
Fatal Python error: Py_EndInterpreter: not the last thread within a second of the abort line that he pasted - could that have been the missing message from the SIGABRT? We just set threads to 1, so I hope that will go away soon - does this look like we might be cauesd by non-threadsafe modules? I've also seen segfaults in the logs recently as well: [Fri Jul 10 09:09:48 2009] [notice] child pid 23582 exit signal Segmentation fault (11) [Fri Jul 10 09:09:48 2009] [info] mod_wsgi (pid=23582): Process 'fas' has died, restarting. [Fri Jul 10 09:09:48 2009] [info] mod_wsgi (pid=24463): Starting process 'fas' with uid=421, gid=421 and threads=2. These are tough to debug since they're happening pretty sporadically - I see 3 in the last 5 hours or so. I guess the next step will be to setup apache to keep core dumps around so that we look into those segfaults more. We'll let you what can get out of that. Thanks, Ricky
pgp95E8G0PO6Z.pgp
Description: PGP signature
