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 _______________________________________________ Tails-dev mailing list [email protected] https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to [email protected].
