Opened 17 years ago

Closed 14 years ago

Last modified 14 years ago

#5677 closed (fixed)

Debugging with mod_python (apache)

Reported by: Manfred Wassmann <manolo@…> Owned by: Nick Efford
Component: Documentation Version: dev
Severity: Keywords: mod_python
Cc: Triage Stage: Ready for checkin
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

This is what the docs say:

If you’re the type of programmer who debugs using scattered print statements, note that print statements
have no effect in mod_python; they don’t appear in the Apache log, as one might expect. If you have the
need to print debugging information in a mod_python setup, either do this:

assert False, the_value_i_want_to_see

Or add the debugging information to the template of your page.

This is not completely true. Everything you write to sys.stderr ends up in the apache error log, like this

import sys
sys.stderr.write('This goes to the apache error log')

Attachments (4)

modpython.diff (1.9 KB ) - added by Nick Efford 17 years ago.
Patch to modpython.txt to clarify use of print statements
5677.diff (1.9 KB ) - added by Tim Graham 15 years ago.
updated patch, including new location of modpython.txt
5677_modpython.diff (1.8 KB ) - added by Daniel Roseman 14 years ago.
Updated patch removing references to WSGI.
5677.2.diff (1.5 KB ) - added by Tim Graham 14 years ago.
updated danielr's patch to apply cleanly trunk

Download all attachments as: .zip

Change History (23)

comment:1 by Malcolm Tredinnick, 17 years ago

Triage Stage: UnreviewedAccepted

If somebody is going to create a patch for this, it must also mention that stderr is buffered in mod_python, so flushing the pipe each time is a necessity if you want to actually see the results in more-or-less realtime.

comment:2 by Graham Dumpleton, 17 years ago

If talking about use of 'print', can you strongly discourage use of 'print' without explicitly directing the output to sys.stderr. Ie., discourage use of:

print 'debug text'

This is because the resulting code is technically not safe to run on all possible WSGI hosting solutions. This is because some WSGI hosting solutions, such as CGI, use sys.stdout to communicate with the core web server. Thus, if users use 'print' without directing it anywhere, the output from it will interleave with valid output being sent back to the client and screw up the response.

So, suggest use of:

print >> sys.stderr, ' debug text'

if anything.

But then as already pointed out, in mod_python this really needs to be:

print >> sys.stderr, ' debug text'
sys.stderr.flush()

What Django developers should perhaps instead consider to get around this, is in the Django mod_python adapter when it is imported, replace sys.stderr with a stream like object which buffers data until an EOL is encountered and then call mod_python.apache.log_error() explicitly. This will ensure that when sys.stderr is used that output appears promptly, it will also attach time stamps to each line of output. Note that if the output passed to the dummy stream object contains embedded EOL, then the line should be split and passed to log_error() one line at a time though.

By doing this sys.stderr replacement, it would avoid all these problems with output not appearing in Apache log in a timely manner. Although one could replace sys.stdout as well, as I said you probably want to discourage people outputing to sys.stdout directly or indirectly.

comment:3 by Nick Efford, 17 years ago

Owner: changed from nobody to Nick Efford

comment:4 by Nick Efford, 17 years ago

Has patch: set
Keywords: sprintdec01 added

Done, incorporating suggestions of Malcolm and grahamd.

by Nick Efford, 17 years ago

Attachment: modpython.diff added

Patch to modpython.txt to clarify use of print statements

comment:5 by Simon G <dev@…>, 17 years ago

Triage Stage: AcceptedReady for checkin

comment:6 by Doug Harris, 17 years ago

What about using standard python logging? Is there a way to get this to go to the error log (or elsewhere)?

in reply to:  6 comment:7 by adroffner@…, 17 years ago

Component: DocumentationContrib apps
Has patch: unset
Keywords: logging modpython mod_python added; sprintdec01 removed
Needs documentation: set
Summary: Debugging with mod_python (apache) improperly documentedLogging errors with mod_python (apache)
Triage Stage: Ready for checkinUnreviewed

Replying to dharris:

What about using standard python logging? Is there a way to get this to go to the error log (or elsewhere)?

I wrote a python logging Handler class, ApacheLogHandler, to do just that. It even supports Apache virtual hosts. Use it the same way as the StreamHandler 'console' object in the Python logging API docs.

I'm trying to make this a clean django.contrib.logging.* feature. Right now it's a Django Snippet.

comment:8 by anonymous, 17 years ago

Component: Contrib appsDocumentation
Has patch: set
Keywords: logging modpython removed
Needs documentation: unset
Summary: Logging errors with mod_python (apache)Debugging with mod_python (apache)
Triage Stage: UnreviewedReady for checkin

comment:9 by James Bennett, 17 years ago

Triage Stage: Ready for checkinUnreviewed

Please don't anonymously bump something to "ready for checkin"; that status implies a certain level of review by an experienced triager.

comment:10 by Thomas Güttler, 17 years ago

Triage Stage: UnreviewedAccepted

This ticket was already accepted (Triage Stage).

comment:11 by Camille Harang, 17 years ago

Another quick solution to get direct output is to print into a tty. Get the tty device by typing 'tty' in a terminal (here /dev/pts/5), and use the small function bellow to print what you need to see:

def print_tty(message, dev='/dev/pts/5'):

    tty = open(dev, 'w')
    tty.write('%s' % message)
    tty.flush()

Example:

print_tty(request.POST)

by Tim Graham, 15 years ago

Attachment: 5677.diff added

updated patch, including new location of modpython.txt

comment:12 by Tim Graham, 15 years ago

Triage Stage: AcceptedReady for checkin

I don't think we can expect to document every possible solution to debugging, but the current patch looks like a good addition.

comment:13 by Karen Tracey, 15 years ago

Triage Stage: Ready for checkinAccepted

I do not like the current patch's inclusion of a vague reference to corrupting client output in "some WSGI hosting solutions". This is text going into the page describing mod_python deployment, specifically. It should limit itself to what happens under mod_python. Sure, adding prints to stdout is a bad idea in other hosting environments too, but that's irrelevant to someone trying to figure out how to debug a problem under mod_python and more likely to cause confusion than anything else.

comment:14 by Joshua Russo, 15 years ago

milestone: 1.2

comment:15 by Russell Keith-Magee, 14 years ago

milestone: 1.2

Deferring due to the absence of a trunk-ready patch.

by Daniel Roseman, 14 years ago

Attachment: 5677_modpython.diff added

Updated patch removing references to WSGI.

comment:16 by Daniel Roseman, 14 years ago

Updated patch removing references to WSGI.

by Tim Graham, 14 years ago

Attachment: 5677.2.diff added

updated danielr's patch to apply cleanly trunk

comment:17 by Tim Graham, 14 years ago

Triage Stage: AcceptedReady for checkin

comment:18 by Simon Meers, 14 years ago

Resolution: fixed
Status: newclosed

(In [14059]) Fixed #5677 -- update modpython stdout documentation. Thanks to Manfred Wassmann for the report, nickefford for the initial patch and Graham Dumpleton for the expert advice.

comment:19 by Simon Meers, 14 years ago

(In [14060]) [1.2.X] Fixed #5677 -- update modpython stdout documentation. Thanks to Manfred Wassmann for the report, nickefford for the initial patch and Graham Dumpleton for the expert advice.

Backported of r14059 from trunk.

Note: See TracTickets for help on using tickets.
Back to Top