[tor-talk] shutdown latencies
japlin at gmail.com
Wed Feb 15 22:47:41 UTC 2012
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!
More information about the tor-talk