On Feb 17, 3:01 pm, Malcolm Tredinnick <malc...@pointy-stick.com> wrote: > > I think I should have clarified some more facts about my setup. > > 1- On mac, django is running on dev mode, so stdout is the console. On > > linux, it'smod_wsgi, so stdout is redirected to apache error log > > files, on which I'm issuing a "tail -f" thorough ssh. > > I was a little surprised that stdout was redirected to the error logs in > mod_wsgi, but it seems that that is indeed the case.
In default configuration mod_wsgi does not send stdout to the Apache error logs. In fact if you try and output to stdout mod_wsgi will complain and raise an exception. This is because mod_wsgi deliberately restricts writing to stdout to discourage people using 'print' for debug. This is done because by doing so you make your WSGI application less portable. In particular, your WSGI application would break in a WSGI hosting mechanism which uses stdout to communicate the response back to the web server. Such a mechanism is used for CGI-WSGI bridges. Thus, if stdout is going to the Apache error logs it is because the user made a conscious decision to redirect it there by disabling the mod_wsgi restriction on using stdout. This can be done by using WSGIRestrictStdout directive, or explicitly reassigning sys.stdout to be sys.stderr. All this stuff about stdout is described in: http://code.google.com/p/modwsgi/wiki/ApplicationIssues#Writing_To_Standard_Output http://code.google.com/p/modwsgi/wiki/DebuggingTechniques > I don't know what > mod_wsgi might be doing to character encoding on output (maybe nothing, > but maybe that's playing a role). Uses: PyArg_ParseTuple(args, "s#:write", &msg, &len) so presumably the default encoding. If the default encoding isn't UTF-8, then you may have problems in trying to output Unicode strings if it cannot be represented in whatever default encoding is. This would likely result in exception and so perhaps what you are seeing. > However, instead of using print, I > would recommend using Python's logging module and sending the results to > a dedicated logging file. > > Apache error logs aren't a great place for audit-style logging, since > there's so much other (Apache-specific) stuff in there. If the integrity of the information being logged is important, then I also would be recommending logging to your own files. The mapping of sys.stderr to Apache error logging mechanism should be seen as more of a failsafe default for minor logging. If you need a more serious logging system, implement your own. Mapping to Apache error logging mechanism has a couple of shortcomings, plus a bug in mod_wsgi 2.3. The bug stems from fact that it is trying to force data into a C API call that takes NULL terminated C strings. Forgot about that aspect of it so it is currently truncating at any embedded null in something which is logged. So, okay if text, but shove binary data down it and it will not be happy. This is addressed in mod_wsgi 3.0. All it can do though is interpret an embedded null as if it was a newline because Apache logging API doesn't understand concept of length. The reason that Apache logging API is used rather than just stuffing it direct into file descriptor for log file, is that it allows Apache to use syslog for logging or for it to be intercepted by any other custom Apache modules that want to process error log messages. Also Apache adds useful date/time information to each line. A limitation of the logging API though is that also has a maximum line length. Thus, it also throws away anything over about 8192 bytes when have a really long line. I am looking at how can easily work around this limitation for mod_wsgi 3.0. Likely will just treat it as if newline had been inserted. The problem though is knowing at what point to artificually insert the newline, as where Apache will truncate it varies based on all the prefix information it adds. Note that the above limitations also apply to wsgi.errors passed in WSGI request environment. Anything output to wsgi.errors also ends up in Apache error log, but also has client and referrer information prefix as well as date/time. It is this referrer information that makes it hard to work out to artificially truncate a line. If the limitations on what successfully gets through with stderr are a problem, then one thing you can do is restore the original Python stderr object. sys.stderr = sys.__stderr__ This will result in it going direct to the main Apache error log. You do need to ensure you explicitly flush the data in stream though to have it appear. Note that whereas sys.stderr for mod_wsgi daemon process defined in VirtualHost context goes to VirtualHost specific error log file, anything sent to sys.__stderr__ will still got to main Apache error log file. This is addressed in mod_wsgi 3.0, with it going to correct VirtualHost specific log file. Anyway, this is probably a lot more detail than what you what you want to know and which is appropriate for this list. For this sort of question a it pertains to mod_wsgi you perhaps would have been better going to the mod_wsgi list. Graham --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~----------~----~----~----~------~----~------~--~---
