CODEWITHSUNDEEP
pythondjangologging
lajarre
lajarre

Reputation: 5162

Django logger - tracebacks not propagating

I replaced all loggers by a catch-all logger in my logging conf in django settings, like:

'loggers': {
    '': {
        'handlers': ['console'],
        'level': 'DEBUG'
    }
}

So I guessed the result would be exactly the same as having the 'django' logger with the same settings. But I'm not seeing the stack trace of errors that are raised (notably on requets), with the above "catch-all" configuration.

Whereas it prints ok again if I add:

'django': {
    'handlers': ['null'],
    'propagate': True
},

It seems that the 'django' logger somehow does the job of adding the traceback to the log?

But anyway what's the reason things behave like that? Why is it that things change when adding the second code snippet? Seems to me there is a part of the story I don't know.

(django 1.5)

Upvotes: 1

Views: 857

Answers (2)

JCotton
JCotton

Reputation: 11760

Try this in settings.py to set a catch-all logger:

LOGGING = {
    'version': 1,
    'root': {'level': 'DEBUG'}
}

Without seeing your full LOGGING setting it's not possible to be sure, but here's my guess for what's happening. I'm not convinced that the empty-string-named '' logger actually works as the root logger; it may do nothing. Additionally, because your settings are not merged with Django's, the 'console' handler won't be defined. If that logger was used, I'd expect it to throw an error like AttributeError: 'str' object has no attribute 'level'. Same with the 'null' handler.

However, when you add that 'django' logger it does correspond with the logger Django actually uses and the propagate setting takes effect bubbling up to the native root logger, which by default prints to sys.stderr. By definition though the root logger catches all things, so you shouldn't have to specifically name a 'django' logger. Again something in your full LOGGING setting could be conflicting.

Upvotes: 0

Vinay Sajip
Vinay Sajip

Reputation: 99355

The only reason I can see for this happening is that the propagation attribute is set to False on the django and/or django.requests loggers by default, and your specifying it explicitly overrides this. In Django 1.5, as compared with earlier versions, the configuration specified in your settings.py can be merged with Django's default, as explained here.

It's generally better to leave propagation alone unless there are specific reasons for overriding the default value of True. Django's own configs sometimes specify True explicitly in the configuration, which IMO serves no purpose other than documenting what would be happening anyway.

You would need to show the complete configuration for the specific 1.5 version of Django you're using to nail down the exact reason for the behaviour you're seeing.

Upvotes: 1

Related Questions