[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: two unseemly tor behaviors

     On Tue, 3 Jul 2007 09:54:01 -0400 Roger Dingledine <arma@xxxxxxx> wrote:

>On Tue, Jul 03, 2007 at 06:50:50AM -0500, Scott Bennett wrote:
>>      I just subscribed to this list, so if the matters I bring up in this
>> message have already been discussed and settled, please just let me know
>> the results.
>>      There are two behaviors of tor running as a server that have been
>> bothering me.  The first is the response to SIGINT w.r.t. the ShutdownDelay
>> value set in torrc.  (I currently run, in case it matters, but the
>> bahaviors I'm complaining about here have been unchanged for at least several
>> releases of tor.)  After SIGINT is received, tor refuses to allow the creation
>> on new circuits through it, so the number of circuits begins to decrease by
>> attrition.  However, even if all circuits have been closed and traffic has
>> decreased to zero, tor does not exit until ShutdownDelay seconds have passed
>> since receipt of SIGINT.  Is there some legitimate reason for this?  I mean,
>> if I need to shut down a server, I usually want to take care of that reason
>> and then get the server back up again ASAP.  I usually keep ShutdownDelay set
>> to about 20 minutes in hopes that most/all activity through the server will
>> cease, so that the shutdown will not break circuits belonging to other people
>> elsewhere.
>The notion of shutting down the server after all the circuits are closed
>has been on the low-priority todo list for a few years. Feel free to
>submit a patch. I bet other people would use this feature too.

     Okay.  Thank you for the reply and the information.  I don't know when
I'll have a chance to dig into tor source code, but if I do, I'll take a look.
Seems like it ought to be something fairly simple to do.
>>      The ShutdownDelay behavior is a nuisance, but the other behavior that
>> has been irritating me is really unforgiveable.  When SIGHUP is received to
>> cause tor to reread torrc, if any errors are found, tor exits very
>> gracelessly, leaving circuits broken and users around the world disgusted
>> with tor as being unreliable software.  I cannot think of any excuse for this.
>> If an error occurs during the parsing of torrc, the error messages should be
>> logged, but either the offending line(s) of torrc should be ignored or the
>> updated torrc as a whole should be ignored and the configuration left unchanged
>> until the next time SIGHUP is received or until tor is next started.
>No, silently ignoring it isn't acceptable either, alas. If you hup tor and
>don't look at the logs, then you'll assume that it magically worked. At
>least this way you learn (eventually) that it hasn't.

     I'm sorry, but I cannot agree.  How is crashing a running server better
than somebody missing a message?  After all, sending SIGHUP is a manual
operation anyway, so it is reasonable to assume that the person doing it is
already paying attention to what he/she is doing, including watching the log.
Leaving the configuration unchanged strikes me as a far better thing.
Immediately at best (the case of someone paying attention) or eventually at
worst (someone not paying attention) the person involved will learn of the
error this way, too, but without inconveniencing all those users whose circuits
get broken at present.  Also, logging the error messages is *not* silently
ignoring the errors.  tor actually seems to be pretty good about logging
intelligible error messages.  "Silently ignoring" would mean *not* issuing
error messages.
     I think anyone who has been patiently waiting for a download to complete
over tor circuit that creeps along at the common tor circuit speed of ~3KB/s
would appreciate more reliable circuits that give a better chance that the
download *will* complete, rather than die 90% of the way through because
someone typed a semi-colon instead of a colon in torrc.
>Now, there is a command-line option to tor called --verify-config. You
>could run it from the script that hups tor, and if --verify-config
>complains, then don't hup tor. The debian initscript does all of this,
>so you could copy the behavior from there if you like.

     Okay, that is a useful tool, and I will try to remember to use it in the
future.  However, it still provides no direct protection to a running tor
server or its current circuits against typos.
>>      A few days ago, I fetched the page at torstat.xenobite.eu.  To my surprise,
>> it listed not a single tor server as stable.
>Hum. Could be. I think that page only looks at a single network status,
>so it may have gotten one that had just rebooted. Or maybe it's a bug.
>>  A document recently appearing at
>> tor.eff.org (I think the one on the v3 directory protocol may have been it)
>> said that from now forward tor servers will have to be up and running for 30
>> days to be considered stable.
>No, you misunderstood. See e.g.

     Oh.  Okay.  Thanks for the link to your explanation.
>>  Having the tor servers crash from typos in the
>> updates to torrc can make it difficult to have "stable" servers.  Can this be
>> easily fixed?
>Hope the above helps.

     It does some.

                                  Scott Bennett, Comm. ASMELG, CFIAG
* Internet:       bennett at cs.niu.edu                              *
* "A well regulated and disciplined militia, is at all times a good  *
* objection to the introduction of that bane of all free governments *
* -- a standing army."                                               *
*    -- Gov. John Hancock, New York Journal, 28 January 1790         *