[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #10006 [Pluggable transport]: Build an obfs-flash PT bundle
#10006: Build an obfs-flash PT bundle
-------------------------------------+-------------------
Reporter: dcf | Owner: dcf
Type: task | Status: new
Priority: normal | Milestone:
Component: Pluggable transport | Version:
Resolution: | Keywords:
Actual Points: | Parent ID: #7167
Points: |
-------------------------------------+-------------------
Comment (by dcf):
Replying to [comment:6 infinity0]:
> Without looking in more detail, my suspicion is that this is #9330
showing up. When Tor kills obfs-flash-client using ProcessTerminate, exit
handlers don't complete and so it never gets a chance to kill all the
children completely (which would explain why you're seeming seemingly
random children living/dying).
#9330 is a good find. I think this problem must be a bit deeper, though.
The thing with Vidalia refusing to run a second time would have been
noticed in a released bundle before now. What children survive isn't
random; it is different in each configuration above, but it was
reproducible within each configuration. (So in the first configuration, it
was always obfsproxy.exe and only obfsproxy.exe that survived.) Also note
that there are two obfsproxy.exe processes: one started by tor.exe for
`obfs2` and `obfs3` (PID 1852), and one started by obfs-flash-client.exe
for `obfs3_flashproxy` (PID 2144); and only the second one (PID 2144) is
continuing to run. So I think it has something to do with the process
nesting.
> BTW, the PT spec states that you need to SIGINT *twice* for a PT to shut
down. When you do Ctrl-C inside the terminal on GNU/Linux, it sends SIGINT
to *all* processes including the children, which is not what you want
since obfsproxy/flashproxy don't yet follow the spec and die on just one
SIGINT - you must "kill -INT" the obfs-flash-client directly, twice.
Alternatively, obfs-flash-client (and anything using
pyptlib.util.subproc.auto_killall) will die and clean up on one SIGTERM.
I think one SIGINT suffices if the transport program is not currently
handling any connections. At least that's how I read ''"Proxies should
respond to a single INT signal by closing their listener ports and not
accepting any new connections, but keeping all connections open, then
terminating when connections are all closed."'' obfs-flash-server
[https://gitweb.torproject.org/pluggable-transports/obfs-
flash.git/blob/064dce29fce2ece3b70efac5c2131a89dd4087cd:/obfs-flash-
server.go#l424 implements it] as I understand it. But you're right,
neither flashproxy-client nor obfsproxy seem to have any fancy signal
handling, so it must not be the case that obfsproxy.exe is simply waiting
for a second signal. C-obfsproxy used to have fancy SIGINT handling
(#3473) and there is a ticket (#9741) for py-obfsproxy. Handling of
SIGTERM (vs. SIGINT) is #9732. I should mention that in the Python wrapper
I tested, I registered handlers for both SIGINT and SIGTERM, and never saw
either (probably because of #9330).
> I'm not sure how that affects Cygwin. But on windows yesterday, I was
able to do a clean shutdown using a standalone obfs-flash-client with
Ctrl-C twice (although I just did that in the console, so possibly it sent
it to the children as well).
Ah, that's good news. What I'll do is upload one of the bundles I built,
and then we can at least test whether this happens on other machines than
mine.
The other thing I would try is to have obfs-flash-client spawn a third
dummy process, both before and after the usual two, and see if it is
killed, or it remains alongside obfsproxy.exe, or it remains and
obfsproxy.exe does not, etc.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/10006#comment:7>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs