Django

Code

Ticket #5677 (new)

Opened 8 months ago

Last modified 1 month ago

Debugging with mod_python (apache)

Reported by: Manfred Wassmann <manolo@NCC-1701.B.Shuttle.DE> Assigned to: nickefford
Component: Documentation Version: SVN
Keywords: mod_python Cc:
Triage Stage: Accepted Has patch: 1
Needs documentation: 0 Needs tests: 0
Patch needs improvement: 0

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

modpython.diff (1.9 kB) - added by nickefford on 12/01/07 20:05:38.
Patch to modpython.txt to clarify use of print statements

Change History

10/03/07 15:17:38 changed by mtredinnick

  • needs_better_patch changed.
  • stage changed from Unreviewed to Accepted.
  • needs_tests changed.
  • needs_docs changed.

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.

10/04/07 18:44:13 changed by grahamd

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.

12/01/07 19:39:11 changed by nickefford

  • owner changed from nobody to nickefford.

12/01/07 20:04:34 changed by nickefford

  • keywords set to sprintdec01.
  • has_patch set to 1.

Done, incorporating suggestions of Malcolm and grahamd.

12/01/07 20:05:38 changed by nickefford

  • attachment modpython.diff added.

Patch to modpython.txt to clarify use of print statements

12/01/07 20:33:10 changed by Simon G <dev@simon.net.nz>

  • stage changed from Accepted to Ready for checkin.

(follow-up: ↓ 7 ) 01/15/08 14:05:53 changed by dharris

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 ) 03/05/08 11:48:28 changed by adroffner@gmail.com

  • component changed from Documentation to Contrib apps.
  • summary changed from Debugging with mod_python (apache) improperly documented to Logging errors with mod_python (apache).
  • keywords changed from sprintdec01 to logging modpython mod_python.
  • needs_docs set to 1.
  • has_patch deleted.
  • stage changed from Ready for checkin to Unreviewed.

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.

03/05/08 11:52:01 changed by anonymous

  • component changed from Contrib apps to Documentation.
  • summary changed from Logging errors with mod_python (apache) to Debugging with mod_python (apache).
  • keywords changed from logging modpython mod_python to mod_python.
  • needs_docs deleted.
  • has_patch set to 1.
  • stage changed from Unreviewed to Ready for checkin.

03/05/08 22:54:19 changed by ubernostrum

  • stage changed from Ready for checkin to Unreviewed.

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

03/06/08 10:07:52 changed by guettli

  • stage changed from Unreviewed to Accepted.

This ticket was already accepted (Triage Stage).

04/11/08 20:49:00 changed by Camille Harang

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)

Add/Change #5677 (Debugging with mod_python (apache))




Change Properties
Action