1) An unexpected exception should be handled as HTTP 500 by Django, with a customized template and eventually extended by debug mode or by debug toolbar. If I think mod_wsgi with Django then I expect usage of django.core.handlers.wsgi.WSGIHandler as it is described in http://code.google.com/p/modwsgi/wiki/IntegrationWithDjango You never use it according the traceback included accidentally in your log. You use some /home/smn/store/wsgi.py Hmm... How you want to handle unexpected exceptions without it?
2) Your logs are good proof of importance of my recent challenge "Django logging in Satchmo" What good solution of logging use all users in production? http://groups.google.com/group/satchmo-users/browse_thread/thread/4f5174a77603d5f5 In your case it looks bad: The first part starts at 13:02:06 and ends at 13:12:18 and continues with approximately 17 kB of zero bytes. The second part (process) starts at 13:12:16 The logs would be later only interveawed or also overwritten. What do you mean? Please, can I use a link to your log as an example to revive that thread? 3) The log of failed request ends with SELECT ... FROM "product_productimage" WHERE ... Before it is a command SELECT COUNT(*) FROM "product_productimage" ... which command is also three times for three requests in the good log and it usually continues by the same sql commands and the last sql command is usually update of expire time of the session. UPDATE "django_session" SET ... "expire_date" = ... but all this missed in the failed log. I am sure that it was an unexpected error. 4) Thanks. I see an error message which should be reported to me ("hynekcer"). You can be calm. It only did not recognized what command or handler exactly is running (probably none of Django handlers is running in your case), but it is not so important because an unknown command or handler has the same consequences as running a webserver handler. I will analyze all similar reports and fix my code if it can be expected that the deployment is correct. (which is not this case) -- Hynek On 22 lis, 20:04, "Philip M. White" <[email protected]> wrote: > On Tue, 2011-11-22 at 10:52 -0800, hynekcer wrote: > > Philip, a runtime error ("500") is probably masked by a bad > > configuration of apache+mod_wsgi. First fix error reporting then fix > > the reported error or ask. > > > 1) An unprivileged user should get a general error message if you try > > some demo Django application with intentionally added DivisionZero > > error in some view. > > > 2) An easy way to get details is to fill ADMINS = (('Your Name', > > '[email protected]'), ) in settings.py and verify that you get an email > > or you can use more advanced ways or try it with debug mode and verify > > that debug mode is not worldwide accessible > > > This is not at all a problem specific to Satchmo or at least one > > general Django problem is there. Satchmo uses by default an error > > message template satchmo_store/shop/templates/500.html if it was not > > in debug mode. > > Hynek, why do you say that this is a runtime error ("500")? Apache > never returns HTTP 500. I filled in the ADMINS tuple and restarted the > server, reproduced the problem, and do not get any email. As far as I > can tell, neither Apache nor Django nor Satchmo realize that anything > went wrong -- or at least there's no indication of anything wrong in > Apache's or Satchmo's logs. > > Here's some new information: satchmo.log on a webpage that refuses to > load, and satchmo.log once I delete the image in the admin interface and > reload that same webpage: > > http://www.qnan.org/~pmw/tmp/satchmo-bad.loghttp://www.qnan.org/~pmw/tmp/satchmo-good.log > > Please tell me if this helps any... > > Thanks again for the replies. -- You received this message because you are subscribed to the Google Groups "Satchmo users" 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/satchmo-users?hl=en.
