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

Re: two unseemly tor behaviors

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.

>      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.

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.

>      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.

>  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.