15 messages in com.googlegroups.pylons-discussRe: mod_wsgi and pylons, Logging| From | Sent On | Attachments |
|---|---|---|
| PyDevler | 14 Nov 2007 17:20 | |
| Graham Dumpleton | 14 Nov 2007 18:20 | |
| PyDevler | 15 Nov 2007 18:51 | |
| PyDevler | 15 Nov 2007 18:56 | |
| Graham Dumpleton | 15 Nov 2007 20:06 | |
| PyDevler | 16 Nov 2007 16:50 | |
| PyDevler | 16 Nov 2007 20:32 | |
| Graham Dumpleton | 17 Nov 2007 20:44 | |
| PyDevler | 24 Nov 2007 19:23 | |
| prog...@public.gmane.org | 19 Dec 2007 15:30 | |
| Graham Dumpleton | 19 Dec 2007 18:27 | |
| Jeff Lindsay | 19 Dec 2007 19:29 | |
| Graham Dumpleton | 19 Dec 2007 21:46 | |
| Jeff Lindsay | 19 Dec 2007 22:41 | |
| Graham Dumpleton | 20 Dec 2007 02:28 |
| Subject: | Re: mod_wsgi and pylons, Logging![]() |
|---|---|
| From: | Jeff Lindsay (prog...@public.gmane.org) |
| Date: | 12/19/2007 10:41:20 PM |
| List: | com.googlegroups.pylons-discuss |
Ok, that makes sense now but only concerns me more because logging in daemon mode is not working, using wsgi.errors or sys.stderr. However, I'm a bit confused because CustomLog is used for access logs, which does work btw if I wasn't clear. It's only error logs that don't work.
-jeff
On Dec 19, 2007 9:47 PM, Graham Dumpleton
<Grah...@public.gmane.org> wrote:
I am only referring to anything output directly via sys.stderr.
Any messages output via wsgi.errors passed in the WSGI environment, which is how most WSGI application would tend to log, would go to the log file associated with the context the request is handled in. If you have a CustomLog in a VirtualHost container, then that is where those messages would go. Any error messages generated by mod_wsgi, including error tracebacks, which correspond to a specific request will similarly be output to the error log file associated with the VirtualHost if CustomLog is used.
The case which differs is when using sys.stderr directly, or where using the logging module since it defaults to using sys.stderr also. Because sys.stderr is global to the interpreter it isn't associated with a specific request and so cannot normally be associated with the custom log of the virtual host. This is the case because technically it is possible for requests against different virtual hosts to be directed to the same interpreter instance.
Daemon mode, where WSGIDaemonProcess is used inside of a VirtualHost, is a special case because in that scenario, that the directive appears inside of the VirtualHost means that only requests bound for that virtual host could be sent to that daemon process. This means that mod_wsgi can associat sys.stderr for that daemon process with the error log for that VirtualHost rather than it going to the global Apache error log.
Graham
On Dec 20, 2:30 pm, "Jeff Lindsay"
<prog...@public.gmane.org> wrote:
That doesn't seem to be the case. We're using this inside our VirtualHost:
ErrorLog /path/to/error_log CustomLog /path/to/access_log combined
We're looking at the error_log file for this vhost and in embedded mode we *do* see Pylons errors when raised but in daemon mode we do not, which seems the opposite of what you say... except that we don't get the errors in the main apache log either when in daemon mode.
This is Gentoo btw.
-jeff
On Dec 19, 2007 6:28 PM, Graham Dumpleton
<Grah...@public.gmane.org> wrote:
Which Apache error log file are you looking in? Do you have VirtualHost specific CusomLog defined?
When run in mod_wsgi daemon mode, the sys.stderr output will be redirected to a VirtualHost specific error log file if WSGIDaemonProcess was defined in the context of the VirtualHost.
When in mod_wsgi embedded mode, the sys.stderr output will always go to the main Apache error log file even if a VirtualHost specific error log file has been defined.
Graham
Actually, I thought I was having the same issue since I was getting no logging at all from Pylons when using mod_wsgi. However, after trying this and it not working, it looks like it has to do with using mod_wsgi in daemon mode. (No, not on FreeBSD this time). I can seem to log from the wsgi script, but once in Pylons it just doesn't spit anything out unless running in embedded mode.
I'm simply using:
WSGIApplicationGroup %{GLOBAL} WSGIDaemonProcess localdev-site user=me group=me WSGIProcessGroup localdev-site WSGIScriptAlias / /path/to/script.wsgi
And I get nothing.
WSGIApplicationGroup %{GLOBAL} #WSGIDaemonProcess localdev-site user=me group=me #WSGIProcessGroup localdev-site WSGIScriptAlias / /path/to/script.wsgi
Will get me exception traces (the main reason I'm doing this) and general logging, without any special setup, just using the default pylons logging config and without the hack mentioned in this thread.
On a dual proc, dual core amd64 setup btw
-jeff
On Nov 17, 8:44 pm, Graham Dumpleton
<Grah...@public.gmane.org>
wrote:
On Nov 17, 3:33 pm, PyDevler <hnas...@public.gmane.org>
wrote:
When I previously mentioned invistigating. I managed to get it to log by manually adding a handler from within my controller-xyz.py. However it is refusing to load my config. It is for some reason refusing to use the Formatter line, that I adjust from within controller-xyz.py. However, it changes the log-level which I also set in the same command I pass the formatter string. I am unable to explain what pylons is doing under mod-wsgi.
Sorry for taking so long to get back to this, got diverted on more important things.
In the documentation for Pylons logging it says:
"""paster, when loading an application via the paster serve, shell or setup-app commands, calls the logging.fileConfig function on that specified ini file if it contains a 'loggers' entry. logging.fileConfig reads the logging configuration from a ConfigParser file."""
This would suggest using 'paster' it does special stuff which wouldn't be getting done if using mod_python, mod_wsgi or any other hosting solution besides 'paster'.
The documentation is a bit deceiving here as took that to mean 'fileConfig' with 'logging' module, but on Python 2.3 at least, no such function exists. Turns out what you need in WSGI script file is:
import os, sys __here__ = os.path.dirname(__file__) __parent__ = os.path.dirname(__here__)
sys.path.append(__parent__)
from paste.script.util.logging_config import fileConfig fileConfig('%s/development.ini' % __parent__)
from paste.deploy import loadapp
application = loadapp('config:%s/development.ini' % __parent__)
Ie., fileConfig comes from 'paste.script_util.logging_config'.
If that function is called with Pylons ini file then logging if then output.
Graham
--
Jeff Lindsayhttp://devjavu.com -- Free Trac and Subversionhttp://blogrium.com--
A blog about things
-- Jeff Lindsay http://devjavu.com -- Free Trac and Subversion http://blogrium.com -- A blog about things




