Re: [Tails-dev] [review'n'merge:1.2] feature/tor-0.2.5.x-alp…

Hi,

I've just seen something weird on a build from experimental, and
I believe it might explain the failures seen by both anonym and
I (although on entirely different scales) with Tor 0.2.5.x.

20-time.sh logged "Tor is now working.", and restarted htpdate, while
Tor was still stuck quite early in its bootstrap process (around 50%,
IIRC). I suspect that the way tor_is_working() works is not adequate
for Tor 0.2.5.x anymore: cached-microdescs.new exists as soon as Tor
*starts* downloading relay descriptors (i.e. just after the bootstrap
50% mark is reached in the Tor log file), so tor_is_working returns
true while Tor is definitely not working yet.

Then, in 20-time.sh we restart htpdate too early, which starts
throwing client circuit requests at Tor while it's still
bootstrapping, and then I see no bootstrap progress in the Tor log for
about 2 minutes, and then it logs about timing out after 120 seconds
to "get a connection to [scrubbed]:443", and then the bootstrap
finishes in 3 seconds.

It seems that this may explain with what I've observed in my last test
report on this thread: basically Tor 0.2.5.x really doesn't like being
requested to open circuits while it's not ready yet (it seems to just
loading relay descriptors for 2 minutes in this deadlocked situation).
It might be that older Tor's didn't like it either, but we simply were
not triggering it due to differences in Tor's behaviour that changes
how our tor_is_working behaves.

anonym, shall we try using tor_bootstrap_progress in tor_is_working,
instead of relying on cached-microdescs* files appearing on
the filesystem?

Cheers,
--
intrigeri