Launchpad itself

lp.services.scripts.logger magic breaks bzr logging

Bug #694140 reported by Jonathan Lange
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Launchpad itself
Triaged
Low
Unassigned

Bug Description

canonical.launchpad.scripts.logger wraps up the root logger and Python loggers in strange ways. Specifically, it breaks the assumed invariant that logging.getLogger('foo') is logging.getLogger('foo').

Thus, when bzrlib.trace caches logging.getLogger('bzr'), it gets one logger, but after c.l.scripts.logger does its thing, logging.getLogger('bzr') returns a *different* logger. This breaks bzrlib.trace.push_log_file, among other things.

The visible impact is that we get lots of errors like:
  No handlers could be found for logger "bzr"

In our test run.

Revision history for this message
Jonathan Lange (jml) wrote :

Oh. lazr.smtptest also has a similar getLogger() caching thing going on. This bug might also be behind the 'No handlers could be found for logger "lazr.smtptest"' thing we have going on.

Tim Penhey (thumper)
tags: added: logging test-system
Changed in launchpad:
status: New → Triaged
importance: Undecided → Low
Revision history for this message
Colin Watson (cjwatson) wrote :

This one thoroughly confused me for a while when writing Launchpad code that uses the germinate module (for lp:~cjwatson/launchpad/refactor-cron-germinate), which does some similar caching things. I eventually found this bug by way of XXX comments, and added a similar workaround to my branch.

Colin Watson (cjwatson)
summary: - canonical.launchpad.scripts.logger magic breaks bzr logging
+ lp.services.scripts.logger magic breaks bzr logging
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.