22/11/12 14:11, intrigeri wrote: > Hi, > > anonym wrote (21 Nov 2012 14:21:43 GMT) : >> Log severity info is really verbose. I ran a test for 20 minutes with >> some rather heavy Tor usage, and the log grew something like >> 100KB/minute. That's too much, IMHO. > > Agreed. > >> However, we can save this approach >> like this: > >> 1. We patch torrc at build time to have "Log info ...", as proposed. >> 2. But once tordate finishes we edit torrc and downgrade to notice >> level debugging, and send a SIGHUP to Tor. > >> Ugly, ugly, ugly workarounds, all the time! :) What do you think? > > Wow... I could live with that, but if there's a trivial bugfix in Tor > itself that can allow us to avoid yet another ugly kludge, then I'd > rather use the possibility thereof.
I tried implementing this in a branch yesterday, hoping to get it in 0.15. I encountered some issues, and then I saw that you had already pushed the 0.15 tag etc. so I didn't look on it again until today. It turns step 2 isn't as easy as I initially thought: Since we're in bridge mode, Vidalia will start before tordate so bridges can be added. When Vidalia connects to Tor, it unsets the (hidden) Tor option "__ReloadTorrcOnSIGHUP", so we either have to: a. restart Tor (and Vidalia) yet again to have Tor re-read the new torrc (now without "info" level logging), or b. manually re-set "__ReloadTorrcOnSIGHUP", send a HUP so Tor re-reads torrc and then possibly unset "__ReloadTorrcOnSIGHUP" again (or restart Vidalia) I don't like either, mostly because this was meant to be a simple, unobtrusive fix. I guess option a is best so Vidalia doesn't get out-of-sync with Tor's state, if that's possible. But it's yet another Tor restart... Note: You can't change anything about "Log" lines in torrc via the control port. Otherwise that'd be the easy way out. I updated the ticket. I'm not >>>> 3. What about patching Tor to eliminate the log severity >>>> inconsistency? But perhaps they have good reasons for this being >>>> the way it is so it wouldn't get upstreamed? >>> >>> I think it's worth asking them if there's a good reason for the >>> apparent inconsistency. > >> On second thought, if we're gonna look towards upstream, I'd rather we >> spend our energy on a proper fix, not a fix that make our current >> workaround work... urgh. > > I don't see these two approaches as incompatible. I wasn't talking about that. I was talking about saving time and energy. > If there are no good reasons for the log severity inconsistency, then > that's a (minor) bug you have discovered in Tor, and I think we should > report it as such, regardless of the solution we choose for the > problem at hand, and regardless of whether we implement a nice new > feature in Tor 0.2.4.x or later. I'll take care of reporting the bug > if needed, just tell me: it'll take me less time to actually do it, > than to argue any longer about whether we should report it or not ;) If you feel like it shoot. > If that works, and Tor 0.2.3.x has this bug fixed $soon, > then problem solved, no kludge to add to our pile and maintain. > Would $soon = end of the year seem reasonable to you? Yes. Cheers! _______________________________________________ tails-dev mailing list [email protected] https://mailman.boum.org/listinfo/tails-dev
