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.
>>> 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.
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 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?
Cheers,
--
intrigeri
| GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
| OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc
