Hi,
anonym, do you want to try and reproduce the issue again, in order to
submit a debug log again?
#1247: bootstrap hickups when network is down
----------------------+-----------------------------------------------------
Reporter: anonym | Type: defect
Status: new | Priority: major
Milestone: | Component: Tor Client
Version: 0.2.1.22 | Resolution: None
Keywords: | Parent:
----------------------+-----------------------------------------------------
Old description:
> 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]
New description:
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]
--
Comment(by arma):
Hm. It looks like we lost the debug.log here in the trac transition? :(
--
Ticket URL: <
https://trac.torproject.org/projects/tor/ticket/1247#comment:2>
Tor Bug Tracker & Wiki <
https://trac.torproject.org/>
The Tor Project: anonymity online
--
intrigeri <intrigeri@???>
| clé GnuPG @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
| empreinte OTR @ https://gaffer.ptitcanardnoir.org/intrigeri/otr-fingerprint.asc
| La curiosité a gardé plus d'une personne en vie alors que tous les
| autres moyens avaient échoué.
