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" <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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
>
> > On Dec 20, 10:30 am, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote:
> > > Hey 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 <[EMAIL PROTECTED]>
> > > wrote:
>
> > > > On Nov 17, 3:33 pm, PyDevler <[EMAIL PROTECTED]> 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
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"pylons-discuss" group.
To post to this group, send email to pylons-discuss@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/pylons-discuss?hl=en
-~----------~----~----~----~------~----~------~--~---
