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

Re: [tor-bugs] #29201 [Core Tor/Tor]: Tor bootstrap hangs when offline

#29201: Tor bootstrap hangs when offline
-----------------------------------+-----------------------------------
 Reporter:  atagar                 |          Owner:  (none)
     Type:  defect                 |         Status:  needs_information
 Priority:  Medium                 |      Milestone:  Tor: unspecified
Component:  Core Tor/Tor           |        Version:
 Severity:  Normal                 |     Resolution:
 Keywords:  040-deferred-20190220  |  Actual Points:
Parent ID:                         |         Points:
 Reviewer:                         |        Sponsor:
-----------------------------------+-----------------------------------

Comment (by atagar):

 Thanks teor. We've been changing our bootstrap behavior quite a bit of
 late (first message format in #28731, and now our offline behavior). This
 is fine, and I'd be happy to work with the network team on the long term
 bootstrapping behavior we want but this feels a bit ad-hoc. Why did we
 change this, and are there more bootstrapping changes coming down the
 pipe?

 Nick added a DROPOWNERSHIP command so in tor versions going forward I can
 avoid parsing stdout logs (#28843). Taking advantage of that is pretty
 high on my todo list, and will let us change bootstrap log formatting at
 will. However, behavioral changes like this will still impact Stem.

 In this particular case I do not mind the behavior change. Stem's tests
 already intend to run when we're 0% bootstrapped so I need to investigate
 this more on my side...

 https://gitweb.torproject.org/stem.git/tree/test/runner.py#n629
 https://gitweb.torproject.org/stem.git/tree/stem/process.py#n170

 Stepping back, maybe we should rethink bootstrapping more fundamentally?
 In particular...

 1. Bootstrap behavior is undocumented. Traditionally this has been fine
 because it never changed.

    Stem and Txtorcon use bootstrapping to determine "Is my tor process
 ready to do X?" where X are things like "make a circuit" or "run a hidden
 service". We don't care about the bootstrap percentage (see below), but we
 use their implication that tor has become ready to do things.

    Our usage is causing you friction. We should use another mechanism or
 formalize this by documenting tor's bootstrapping behavior including what
 the various percentages (or messages) mean.

 2. If we're going to rethink bootstrapping maybe we should go further? Why
 do we even present bootstrapping as percentages? Does this make sense?

    Said another way, if "tor is 13% boostrapped" what does that mean? It
 isn't a time estimate (we're not saying that we're 13% done). It's also
 not saying that tor is capable of 13% of its capabilities.

    I suspect bootstrap percentages might be a holdover from Vidalia's
 progress bar, which from a user perspective always stunk (descriptor
 downloads usually dominate bootstrapping so the bar jumped to ~55%, hangs
 for a minute, then jumps to 100%).

    Obligatory video: https://www.youtube.com/watch?v=1V2SHW6Qx_E

 Just spitballing, but how about the following?

 1. Drop the bootstrap percentage.
 2. Define bootstrap logging as purely informational (ie. controllers like
 Stem should not use it).
 3. Add GETINFO commands that answer any "Is tor ready to do X?" inquiries.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/29201#comment:4>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online

_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs