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!
