Check if we can stop restarting tor in 10-tor.sh
Restarting tor via NM, without coordination with Tor Connection, causes all sorts of trouble. Here's the code: ``` # We would like Tor to be started during init time, even before the # network is up, and then send it a SIGHUP here to make it start # bootstrapping swiftly, but it doesn't work because of a bug in # Tor. Details: # * https://gitlab.torproject.org/tpo/core/tor/-/issues/1247 # * https://gitlab.tails.boum.org/tails/tails/-/blob/7fae4a761a06e5a14048baff21e0bdb71a1f7226/wiki/src/bugs/tor_vs_networkmanager.mdwn # To work around this we restart Tor. systemctl restart tor@default.service ``` Above links, but clickable: - https://gitlab.torproject.org/tpo/core/tor/-/issues/1247 - https://gitlab.tails.boum.org/tails/tails/-/blob/7fae4a761a06e5a14048baff21e0bdb71a1f7226/wiki/src/bugs/tor_vs_networkmanager.mdwn Is this still necessary? Would a SIGHUP (aka. `systemctl reload tor@default.service`) suffice? # Test plan - [ ] Check how this relates to http://eweiibe6tdjsdprb4px6rqrzzcsi22m4koia44kc5pcjr7nec2rlxyad.onion/tpo/core/tor/-/issues/40499 - [x] Check if in the most trivial scenario, a SIGHUP is sufficient: 1. start Tails 2. close _Tor Connection_ 3. replace this `restart` with `reload` 4. connect to Tor via _Tor Connection_ 5. disconnect from the network 6. wait 15 minutes 7. reconnect to the network 8. tor should resume working - _Tor Connection_ waits for direct connection to bootstrap, which times out: actually, Tor as already bootstrapped and is working fine, so it does not need to bootstrap again, but apparently _Tor Connection_ does not know this. Essentially, the `restart` we currently have hides a more fundamental disconnect between the actual status of the tor client and the status of `tails-tor-has-bootstrapped.target`; once we don't force a new bootstrap anymore via restarting, the problem becomes visible: in some cases tor has bootstrapped but that systemd target is down, which makes some sense since tor is not usable (we're offline, remember), but is problematic because _Tor Connection_ does not know it should not wait for a bootstrap to happen. - then _Tor Connection_ retries using default bridges, which successfully bootstraps - [x] Trivial scenario, but waiting 2+ hours in order to gain confidence that waiting 15 min is sufficient for the remaining tests: same result as when waiting 15 minutes - [ ] Trivial scenario, but with default bridges - [ ] Trivial scenario, but with custom bridges - [ ] Suspend to RAM and resume 15 minutes later - [ ] Disconnect then reconnect from a different network 15 minutes later - [ ] Brainstorm more elaborate test scenarios, aka. "what can possibly go wrong if we reload instead of restarting?"
issue