Sorry, got myself confused, where I said CustomLog I meant ErrorLog.
Can you summarise what works and doesn't for basic use case inside a
hello world application. Ie., what gets output to Apache error log
(and which one) for the following:
import sys
def application(environ, start_response):
status = '200 OK'
output = 'Hello World!'
print >> sys.stderr, "sys.stderr"
print >> environ["wsgi.errors"], "wsgi.errors"
response_headers = [('Content-type', 'text/plain'),
('Content-Length', str(len(output)))]
start_response(status, response_headers)
return [output]
This will tell me if we are talking about an underlying mod_wsgi
issue, or something specific to how Pylons does logging.
Note that LogLevel directive in Apache must be at least 'error' for
either of these to be displayed. Generally the default is 'warn' which
should capture them.
If both of those works in both embedded and daemon mode, but a Pylons
specific application is not generating anything to error log when you
expect it, can you give a small example which would demonstrate the
problem.
Thanks.
Graham
On Dec 20, 5:41 pm, "Jeff Lindsay" <[EMAIL PROTECTED]> wrote:
> 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 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
-~----------~----~----~----~------~----~------~--~---
