[tor-talk] shutdown latencies

[Justin Aplin]

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