[tor-bugs] #11156 [Tor]: "can't find a pluggable transport proxy" errors when obfsproxy started up

[Tor Bug Tracker & Wiki]

#11156: "can't find a pluggable transport proxy" errors when obfsproxy started up
-------------------------+-------------------------------------------------
     Reporter:  asn      |      Owner:
         Type:  defect   |     Status:  needs_review
     Priority:  normal   |  Milestone:  Tor: 0.2.4.x-final
    Component:  Tor      |    Version:
   Resolution:           |   Keywords:  024-backport tor-pt tor-client,
Actual Points:           |  tbb-needs
       Points:           |  Parent ID:
-------------------------+-------------------------------------------------

Comment (by asn):

 I think there might be a bug in my patch here.
 My fix doesn't seem to interact well with the RESETCONF control command.

 I attached an info-level log from the current tor master when used with
 OONI.
 OONI uses txtorcon which sends the `RESETCONF` signal.

 If you check the logs, you can see the pluggable transport proxy is
 configured properly. But at some point the torrc is re-read (there is a
 second `opening log file` message) and from that point things go weird.

 Specifically, the transport proxies are marked as HUPed (which means that
 Tor is supposed to examine them in case they need to be restarted), and
 when Tor reaches `should_delay_dir_fetches()` it delays the dir fetches
 because `pt_proxies_configuration_pending()` returns true because of
 `check_if_restarts_needed` is true (because the proxies got HUPed).

 Then for some reason, it hits `should_delay_dir_fetches()` a few more
 times in the same second and then it decides that the bridge is unusable
 and kills it. Then it finally reaches the end of `run_scheduled_events()`
 where it runs `pt_configure_remaining_proxies()` and decides that the
 proxy doesn't need to be restarted (` pt_configure_remaining_proxies():
 Nothing changed for managed proxy '/usr/local/bin/obfsproxy' after HUP:
 not restarting.`).

 If `should_delay_dir_fetches()` was run after that, it wouldn't delay and
 the fetches would run normally. However at that time, the bridge is
 already dead...

 I tried to reproduce this by doing SIGHUP (so that I can attach a
 debugger) but it worked fine. I'm wondering wy all the
 `should_delay_dir_fetches()` were ran in the same tick.

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