Use the 'owning controller' feature in ooni-probe/bridget

15:26:50 < rransom_> I would also recommend using the 'owning 
                     controller' feature (#3049) to ensure that stray 
                     Tor processes don't stay around for long.

added component::archived/ooni owner::hellais priority::medium resolution::fixed status::closed type::enhancement labels

Is this command inside of PyTorCtl? Stem?

Trac:
Cc: N/A to rransom

Replying to hellais:

Is this command inside of PyTorCtl? Stem?

How should I know? I don't use either.

Read section 3.23 of control-spec.txt for how to use this feature.

Is this command inside of PyTorCtl? Stem?

Nope. This feature was not added to TorCtl and Stem will support it but isn't yet feature complete. Sorry. :(

Ok, is it safe to think of this as a future enhancement, but not work on implementing it right now?

Replying to hellais:

Ok, is it safe to think of this as a future enhancement, but not work on implementing it right now?

Only if you're certain that your bridge tester will never crash.

If you leave old Tor processes running, they will continue to occupy their SOCKS and control ports. If you leave old Tor processes running and delete their data directories, they will probably break far more spectacularly. Don't leave old Tor processes running.

The ‘owning controller’ feature is the easiest way to not leave old Tor processes running. If you don't want to set one command-line option and send two control-port commands, you'll have to find some other way to identify still-running Tor processes and end them before your datadir-reaper process makes them go truly crazy.

We have now switched to using txtorcon for bridget and txtorcon implements the TAKECONTROL 'owning controller' feature already (http://txtorcon.readthedocs.org/en/latest/)

Closing it as resolved.

Trac:
Resolution: N/A to fixed
Status: new to closed

closed