Opened 9 years ago

Last modified 18 months ago

#1247 new enhancement (None)

bootstrap hickups when network is down

Reported by: anonym Owned by:
Priority: High Milestone: Tor: unspecified
Component: Core Tor/Tor Version: 0.2.1.22
Severity: Normal Keywords: performance, bootstrap, tor-client, sponsor8-maybe
Cc: anonym, nickm, intrigeri, arma, Sebastian, ilter, adrelanos@… Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description (last modified by arma)

In short, if the network is down when tor starts for the very first time
the bootstrapping process might take a very long time (or never finish)
even if the network is connected just shortly after tor starts and finds
out that it's offline.

This has been a major issue in live distributions like Incognito and amnesia
for years becase:

1) they use a system-wide tor process that starts before xorg, and since
they use NetworkManager, the network isn't up until they xorg has started.
2) they have an empty tor data directory, so they must bootstrap each
time they start.

That windows of 10-20 seconds or so of no network can make tor take
anything from no time to hours to days to finally realise that the
network is there and it can finish bootstrapping and start working. The
time it takes seems extremely random, but usually it's done within 10
minutes or so, but that's still very bad.

The only thing that seems to speed this up is to restart tor when the
network is up (which admittedly is quite easy to automate with something
like if-up.d or NetworkManagers event dispatcher). When that is done,
tor immediately bootstraps and is usable within 10 seconds.

It would of course be preferable if tor could handle it cleanly and fast
itself, or if it could be "prodded" somehow. For instance, I hoped
sending tor a SIGHUP would make it re-try getting in touch with the
directories, but it doesn't. Having an application use tor (so that it
"optimistically will try to fetch a directory") doesn't help either. To
me it seems that if tor is stuck with getting dir info, any external
prodding to get it to do it again is ignored.

I can easily reproduce this problem the following way:

1) start amnesia in virtualbox and let it get into an X session.
2) stop the tor process and disconnects the network.
3) clear the tor data directory and start tor.
4) wait one minute, then connect the network.
5) check the logs for how long it takes until tor bootstraps since
the network was connected.

I'll attach a debug level log of how this looks for me.

My desired result woulb be that the time measured in step 5
would be at most 10 seconds. Optimally tor should be able to detect
that the network is up again completely on its own, but I'm
equally happy if it could be "prodded" to check for the net again,
like seding tor a SIGHUP, application request, control port command
or anything that can be easily scripted.

[Automatically added by flyspray2trac: Operating System: All]

Child Tickets

TicketTypeStatusOwnerSummary
#2150defectclosedchiiphAutoconnect to a tor instance loaded after startup

Attachments (1)

debug.log (98.8 KB) - added by anonym 9 years ago.
The same log (sometimes it's good to be messy and con't clean one's home!)

Download all attachments as: .zip

Change History (13)

comment:1 Changed 9 years ago by anonym

In the attached debug.log, tor is started (with no network) at 06:09:44.910,
and the network is plugged in at 06:11:45.007 (so I waited two minutes this
time, but it seems it makes no difference if you wait 10 seconds, 1 minute,
2 minutes, an hour, or whatever) when it receives a SIGHUP (dispatched by
NetworkManager). Approximately five minutes later, at 06:15:51.916,
bootstrapping continues and tor is up an working just seconds later.

comment:2 Changed 9 years ago by arma

Description: modified (diff)

Hm. It looks like we lost the debug.log here in the trac transition? :(

Changed 9 years ago by anonym

Attachment: debug.log added

The same log (sometimes it's good to be messy and con't clean one's home!)

comment:3 Changed 9 years ago by anonym

It should be noted that we have a (hackish) workaround for this bug in
T(A)ILS nowadays (we just restart tor each time the network is up:ed),
so it cannot be reproduced using it.

comment:4 Changed 9 years ago by nickm

Milestone: Tor: 0.2.3.x-final

comment:5 Changed 8 years ago by arma

Keywords: performance bootstrap added

comment:6 Changed 7 years ago by nickm

Milestone: Tor: 0.2.3.x-finalTor: unspecified
Type: defectenhancement

This is important, but would require a new feature to fix

comment:7 Changed 7 years ago by nickm

Keywords: tor-client added

comment:8 Changed 7 years ago by nickm

Component: Tor ClientTor

comment:9 Changed 6 years ago by proper

Cc: adrelanos@… added

Is there any workaround other than restarting Tor (some control port command)?

comment:10 Changed 5 years ago by intrigeri

comment:11 Changed 2 years ago by nickm

Keywords: sponsor8-maybe added

comment:12 Changed 18 months ago by teor

Severity: Normal

Set all open tickets without a severity to "Normal"

Note: See TracTickets for help on using tickets.