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 <[EMAIL PROTECTED]> 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" <[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
>
> >
>



-- 
Jeff Lindsay
http://devjavu.com  -- Free Trac and Subversion
http://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 [email protected]
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
-~----------~----~----~----~------~----~------~--~---

Reply via email to