[tor-bugs] #9199 [BridgeDB]: Rethink the logging of BridgeDB

Tor Bug Tracker & Wiki blackhole at torproject.org
Thu Jul 4 11:44:28 UTC 2013

#9199: Rethink the logging of BridgeDB
 Reporter:  asn       |          Owner:                   
     Type:  task      |         Status:  needs_information
 Priority:  normal    |      Milestone:                   
Component:  BridgeDB  |        Version:                   
 Keywords:            |         Parent:                   
   Points:            |   Actualpoints:                   
Changes (by isis):

 * cc: isis@… (added)


 Oops. I forgot to mark on #3797 that I was working on the logger, but a
 general ticket is better. Also, oops: sysrqb, I don't mean to step on your
 toes if you're working on this, but I'll post what I've already done.

 In reply to [comment:2 asn]:
 > Hm. How hard would it be to switch to twisted.logging? What are the
 advantages of using Twisted logging? Do we care about them?

 The stdlib logging module, and most of stdlib´s IO utility modules as
 well, are not compatible with Twisted, due to the default way that Python
 handles file locks. From what I've understood from discussions on the
 twisted-dev list, using any of these modules can result in the weird
 Twisted bugs that pop up one-in-every-thirty-seven-times the program is
 run, and in general suck to try to debug.

 My updates to the logging facilities (using Twisted's logger) and
 configuration loader so far are in
 logging this branch on Github].

 As far as asn's ideas at the beginning of this ticket go, setting up a
 Filter for log emission to remove IP addresses shouldn't be too hard. And
 if there's any useful info that could safely be collected for metric or
 something else, that should be doable, though I don't know what info that
 might be as I am not super familiar with BridgeDB yet.

 I was also thinking that it might be a good idea to rewrite the startup()
 parts of Main.py to be a twisted.application.Application, as then we would
 nearly-automatically get different logger contexts for different
 services/servers, daemonisation, resource control, and the like, though I
 should probably create a separate ticket for this.

Ticket URL: <https://trac.torproject.org/projects/tor/ticket/9199#comment:4>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online

More information about the tor-bugs mailing list