2009/6/30 Ricky Zhou <[email protected]>: > Hey, I'm working with Mike on debugging these 500s. > > On 2009-06-30 08:40:52 AM, Graham Dumpleton wrote: >> Any chance you can upgrade to mod_wsgi 2.5. Various issues have been >> fixed between 2.1 and 2.5 and wouldn't rule out that problem has >> already been fixed. > Sure, we can try reproduce with with a mod_wsgi 2.5. As a side > question, do you think the various bug fixes from 2.1 to 2.5 are > significant enough that the mod_wsgi package in the EPEL repository > should be updated?
The main bug fixes are number 4 in: http://code.google.com/p/modwsgi/wiki/ChangesInVersion0202 Number 2, 4 and 5 in: http://code.google.com/p/modwsgi/wiki/ChangesInVersion0204 The wsgi.file_wrapper fixes may not be an issue if TG doesn't use it. The main one would be worried about is the memory corruption problem. This has been the source of a few obscure random problems. > We usually try to only update EPEL packages for > important bugfixes in order to keep those packages as stable as > possible, but I'd be happy to talk to the maintainer about it if it > should be updated. My 2.X versions are pretty well bug fixes only. Version 3.X is next major feature update. >> BTW, do you have TG setup so as to capture internal 500 error messages >> and send an email or something when they occur. Often frameworks will >> internally capture Python exceptions, generate a 500 error page but >> not log anything. Instead you are expected to configure it to log it >> or email details to someone when run in a production setting. > For all other errors that we have faced so far, TurboGears does show the > tracaback in the error log. > > We did try wrapping our application in error reporting middleware, but > we never received any notifications when the 500s occured. We also > attempted wrapping some simple middleware around our application which > would run the application in between two print statements. When the > 500s occured, the first print showed up in the logs, but the second > didn't :-/ Can you think of any anything that could kill the > application like that without mentiong in the error log? Yes, the daemon process crashing. This should show though as a 'Segmentation fault' message, possibly only in main (not VirtualHost) Apache error log. Depending on where in request processing it occurs, you might only see it as truncated response. If before or during headers returned from application though, you could get an Apache level error message of the form: Premature end of script headers BTW, I presume the second print was in a 'finally' clause of a 'try/finally' to ensure it is printed even when exception occurs. Anyway, trying monitoring daemon processes and whether they disappear when they shouldn't. Using LogLevel of info may assist with that. Graham --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "modwsgi" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/modwsgi?hl=en -~----------~----~----~----~------~----~------~--~---
