#5085: managed obfsproxy does not quit if tor dies ---------------------------+-------------------- Reporter: arma | Owner: asn Type: defect | Status: new Priority: minor | Milestone: Component: Obfsproxy | Version: Resolution: | Keywords: Actual Points: | Parent ID: #10047 Points: | ---------------------------+--------------------
Comment (by dcf): I had to solve this problem for meek-client-torbrowser on Windows. meek- client-torbrowser starts two of its own subprocesses, and on Windows, tor kills its PTs uncleanly with TerminateProcess (#9330), hence they don't have a chance to clean up their subprocesses. What I did was described in comment:5:ticket:10047. You stick another process (called terminateprocess-buffer) in between tor and the real PT (meek-client-torbrowser). tor kills terminateprocess-buffer uncleanly. The real PT senses that its stdin has closed, and uses that as a signal to shut down cleanly. How this would work in the obfsproxy case is you would put the buffer process in between tor and obfsproxy, and modify obfsproxy to monitor the closedness of its stdin. The buffer source code looks like this: https://gitweb.torproject.org /pluggable- transports/meek.git/blob/ff595f26a6be2c4ca58637e04c012b804e69617e :/terminateprocess-buffer/terminateprocess-buffer.go. Unfortunately, tor closes the stdin of its PT processes on startup, so the PT has to know whether it is being run with a terminateprocess-buffer or not, and interpret the closing of stdin appropriately. In meek-client- torbrowser, this is done with a special --exit-on-stdin-eof option. -- Ticket URL: <https://trac.torproject.org/projects/tor/ticket/5085#comment:5> Tor Bug Tracker & Wiki <https://trac.torproject.org/> The Tor Project: anonymity online _______________________________________________ tor-bugs mailing list tor-bugs@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs