Cannot find place where pyramid application writes logs

1180 views
Skip to first unread message

Sergei Stolyarov

unread,
May 21, 2012, 5:01:59 AM5/21/12
to pylons-...@googlegroups.com
I'm using the following code for debug logging:

import logging
log = logging.getLogger(__name__)
...
log.debug()

When using command ``pserve --reload development.ini`` logs are
printed fine, but my application is executed on uwsgi/nginx I cannot
find where my debug output goes. UWSGI log contains just uwsgi related
stuff. I use the same development.ini for both paster and uwsgi modes.

Could you please explain how this logs could be enabled?

--
Sergei Stolyarov

Jonathan Vanasco

unread,
May 21, 2012, 12:37:52 PM5/21/12
to pylons-discuss
http://docs.pylonsproject.org/projects/pyramid/en/latest/narr/logging.html?awesome

Under "Advanced Configuration"

"""To capture log output to a separate file, use a FileHandler (or a
RotatingFileHandler):"""
( instructions continue )

Also, you'll note at the top of the docs:
"""The pserve command calls the logging.fileConfig function using the
specified ini file if it contains a [loggers] section (all of the
scaffold-generated .ini files do). logging.fileConfig reads the
logging configuration from the ini file upon which pserve was
invoked"""

So all the logging facilities are provided by the standard library
here:
http://docs.python.org/library/logging.html

Marius Gedminas

unread,
May 21, 2012, 3:37:25 PM5/21/12
to pylons-discuss
On Mon, May 21, 2012 at 09:37:52AM -0700, Jonathan Vanasco wrote:
> http://docs.pylonsproject.org/projects/pyramid/en/latest/narr/logging.html?awesome
>
> Under "Advanced Configuration"
>
> """To capture log output to a separate file, use a FileHandler (or a
> RotatingFileHandler):"""
> ( instructions continue )
>
> Also, you'll note at the top of the docs:
> """The pserve command calls the logging.fileConfig function using the
> specified ini file if it contains a [loggers] section (all of the
> scaffold-generated .ini files do). logging.fileConfig reads the
> logging configuration from the ini file upon which pserve was
> invoked"""

Note that it's pserve that does this.

If you use something else (e.g. uwsgi, with which I'm entirely
unfamiliar), you have to ensure it configures logging for you.

Google tells me uwsgi has a --ini-paste-logged option ("only availabe in
the development version" according to a blog post dated February 2012).

Marius Gedminas
--
Please do not even think about automatically normalizing file names
anywhere. There is absolutely no need for introducing such nonsense, and
deviating from the POSIX requirement that filenames be opaque byte
strings is a Bad Idea[TM] (also known as NTFS).
-- Markus Kuhn
signature.asc

Sergei Stolyarov

unread,
May 22, 2012, 12:36:38 AM5/22/12
to pylons-...@googlegroups.com
On Tue, May 22, 2012 at 2:37 AM, Marius Gedminas <mar...@gedmin.as> wrote:
> If you use something else (e.g. uwsgi, with which I'm entirely
> unfamiliar), you have to ensure it configures logging for you.
>
> Google tells me uwsgi has a --ini-paste-logged option ("only availabe in
> the development version" according to a blog post dated February 2012).

Thanks, you're right, actually it's already in released code. To
correctly use it ini file for uwsgi should looks like:

[uwsgi]
...
ini-paste-logged = /home/user/projects/abc/development.ini
...

And also pypi package `pastescript` should be installed to display
complete output from pyramid app logging output.

--
Sergei Stolyarov

Daniel Holth

unread,
May 22, 2012, 10:41:44 AM5/22/12
to pylons-...@googlegroups.com
Here's a way to work without implicit logging configs.

In development.ini, create a setting that references the logging config file (which is the same file):

[app:myapp]
logging.config = %(here)s/development.ini

At the top of app(global_config, **settings):

logging.config.fileConfig(settings['logging.config'])

Marius Gedminas

unread,
May 22, 2012, 3:48:49 PM5/22/12
to pylons-...@googlegroups.com
I would also recommend passing disable_existing_loggers=False when you
call fileConfig(), to avoid mysteriously disappearing log messages.

(More info at http://mg.pov.lt/blog/logging-fileconfig-gotcha.html)

Marius Gedminas
--
"If you think C++ is not overly complicated, just what is a protected abstract
virtual base pure virtual private destructor, and when was the last time you
needed one?"
-- Tom Cargil, _C++_Journal_
signature.asc

Jonathan Vanasco

unread,
Jun 8, 2012, 5:57:28 PM6/8/12
to pylons-discuss
now that i'm trying uwsgi , i'm running into the same situation

would anyone mind sharing their configuration for logging under this?
it's really hard to troubleshoot my integration right now.

Jonathan Vanasco

unread,
Jun 9, 2012, 8:23:39 PM6/9/12
to pylons-discuss
I eventually figured some stuff out.
I figured I'd post my learnings here -- it's largely a recollection of
the above, but with some context:


Configuring your environment.ini or app
---------------------------------------

for simplicity, you can put everything into a uwsgi block.
all of these can be dropped into `uwsgi` command line options , shown
below

[uwsgi]
socket = /tmp/my_pyramid_app.sock
master = true
processes = 1
daemonize = /var/log/uwsgi/my_pyramid_app-uwsgi.log
pidfile = /tmp/my_pyramid_app.pid
virtualenv = /webserver/environments/my_pyramid_app-2.7/

commandline equivalents , for spawning the uwsgi server
socket = -s | --socket
master = -M | --master
processes = -p | --processes
daemonize = -d | --daemonize
pidfile = --pidfile
virtualenv = -H | --home | --virtualenv | --venv | --pyhome



Spawning the uwsgi server
-------------------------

This will spawn the uwsgi server , but only log uwsgi events. ie, no
Python logging

$ uwsgi --ini-paste /path/to/your/environment.ini


This will spawn the uwsgi server with Python logging

$ uwsgi --ini-paste-logged /path/to/your/environment.ini

If you don't have a [uwsgi] block in your environment.ini , you need
to pass in all the commandline equivalents ( see above )

uwsgi has *a lot* of commandline options. `uwsgi --help` will list
them all.

Misc issues
-----------

1) wrong app version running

This particular project was in subversion , so I ran into an issue
while testing my tags/current_production after I merged from trunk.

I ran `python setup.py develop` in the virtualenv under the tag to
switch the package and ensure things were working. My debugging never
showed up, and I thought logging was broken. After an hour of
troubleshooting, I finally realized that the issue wasn't with the .py
files but the .pyc files. I ran a cleanup script on the tag and trunk
(just removes all the .pycs), and then uwsgi started serving the right
files. Not sure how/why this happened, but if anyone has issues with
it, that might help.


2) trouble compiling uwsgi on osx

uwsgi wouldn't install for me. i kept getting issues regarding the
architecture that pcre was built on. installing a new pcre didn't
work.

i eventually figured out :

uwsgi constantly thinks the mac is x86_64
pcre constantly thinks the mac is i386


if this happens to you, to get around this when compiling PCRE:

./configure CC="gcc -arch i386 -arch x86_64" \
CXX="g++ -arch i386 -arch x86_64" \
CPP="gcc -E" CXXCPP="g++ -E" \
--prefix=/path/to/your/virtualenv
make
make install
file /path/to/your/virtualenv/lib/libpcre.dylib

when you `file` the libpcre.dylib , you should see it built for
multiple architectures , one of which should match what uwsgi wants.
Reply all
Reply to author
Forward
0 new messages