launch_tor hangs when ControlPort is set to 0

[hellais]

If you run the following snipped you will see what I mean:

from twisted.internet import reactor
import txtorcon

config = txtorcon.TorConfig()
config.SocksPort = 9999
config.ControlPort = 0

def progress_updates(prog, tag, summary):
    print "%s %s %s" % (prog, tag, summary)

d = txtorcon.launch_tor(config, reactor, progress_updates=progress_updates)
@d.addErrback
def eb(failure):
     print failure
@d.addCallback
def cb(result):
     print result
reactor.run()

I would expect either to see some of the progress updates or some errback being fired message to be triggerred, but instead it just hangs.

Note that if the config.ControlPort = 0 line is commented out it works just fine.

[meejah]

txtorcon depends on talking to the launched Tor after it starts up; if you don't set controlport at all, it will set one itself but if you do it passes your setting through. I haven't double-checked, but I'd guess Tor interprets 0 as "no control port, please" since that's what SOCKSPort=0 means...

Still, this is a bug that txtorcon could/should detect and deal with...

Thanks for the report :)

[meejah]

@hellais what is the use-case here for having ControlPort set to 0?

[hellais]

@meejah the use case is that I need to disable setting the control port when starting tor as root. Failing to do so will lead to some permission errors. Also it does not make sense for me to have the control port enabled when I just need to start tor for proxying requests via the socksport.

[meejah]

Okay, doesn't seem impossible to support. I'd either have to add a "control_port=False" or similar to launch_tor() so it can skip all the "needs controller" bits. Or, I suppose, just detect that ControlPort is 0...

Does it make sense to ultimately get back a TorProcessProtocol object in this case? It would also then be up to the user to kill off the Tor, I suppose :/

[meejah]

Now in master, just pass a TorConfig upon which you've run "config.ControlPort=0" first and it should Just Work. Note we don't wait for the tor to be bootstrapped, and the caller is responsible for killing the underlying process.

Perhaps these two limitations could be improved upon, but for now they're limitations...