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

Re: [tor-talk] shutdown latencies

On 2/15/2012 3:31 PM, eliaz wrote:
Thanks, this gives me someplace to start.

On 2/15/2012 1:52 PM, Justin Aplin wrote:
On Feb 15, 2012, at 12:48 PM, eliaz wrote:
I've set ShutdownWaitLength to 30 minutes in  torrc.
If this is actually set to 30 minutes, and not 30 seconds, I believe
that's your problem
I do other things besides maintain a bridge on this machine; I've set a
half-hr timeout so that I can shut down when necessary&  then restart
before the bridge goes down. I thought this would make it easier on the
network&  the people using the bridge.

I think you're misunderstanding the point of the clean shutdown procedure slightly. Bridges, exits, and middle nodes publish new server descriptors every time they start, regardless of what their shutdown state was. So when you reboot your machine, it's not coming back up "before the bridge goes down", the bridge was "down" as soon as its process was killed in the shutdown. The new instance on the newly rebooted machine will be added to the network as soon as Tor starts again.

People who already have your IP/fingerprint listed as one of their bridges will be able to resume using your node as soon as the Tor process starts running again.

When for some reason I have to press "Stop Tor" and get the message
"Would you like to shut down gracefully and give clients time to find a
new relay?" along with the red onion icon, what exactly does
this mean?

It signals your node to stop accepting new connections, and not
renew existing ones when they end. This allows those clients who were
connected through your node to smoothly transition to a new node without
interruption. At the end of the ShutdownWaitLength timeout, all
connections are killed regardless, and the node shuts down.
I think I understand you to mean that the clients (nodes) are talking
code to each other, and the actual users don't even notice that the
bridge is gone&  they're on a new path. Is this correct?

This is true as long as the user has more than one bridge listed. When yours stops accepting connections, their client will automatically switch to another, (hopefully) providing an uninterrupted connection. The same is true for users not using bridges, except that they have a much larger pool of new nodes to pull from, since they don't have to list which ones to use manually.

The icon seems to sit there forever
I exaggerated; I guess I've been too busy (aka too damned impatient) to
wait more than 30 minutes... Thanks again - eliaz

Since your node stops accepting new connections as soon as its shutdown process starts, it may actually better serve the network to have a short shutdown time (say, a minute or so). Say, theoretically, several people usually use your node at once, and only one of them is holding up the shutdown process, this limits the usability of your bridge for that half hour or so to just that one person. If you get the reboot over with quickly, however, you get the node back up in its fully-working state, able to accept multiple connections, much faster.

The fact that Tor is taking the full 30 minutes to shut down is bothering me, as I've never seen that behavior before. I have a hunch that there is one or more people out there for whom you are the only bridge (or the only working bridge) on their list, so they have nobody to switch to when you shut down. There's nothing you can do about that, however, and I'd still recommend the shorter timeout above.

Thanks for running a bridge!

~Justin Aplin

tor-talk mailing list