GitLab

It looks like a single SIGINT kills obfsproxy, contrary to what https://gitweb.torproject.org/torspec.git/blob/HEAD:/proposals/180-pluggable-transport.txt says: 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. Proxies should respond to a second INT signal by shutting down cleanly. It looks like #3473 (closed) was this issue in C-obfsproxy.

Here is what I see in the debug log when I SIGINT tor. I think the message "Received SIGINT, shutting down" comes from Twisted.

2013-09-14 10:21:09,672 [INFO] Received SIGINT, shutting down.
2013-09-14 10:21:09,672 [INFO] Received SIGINT, shutting down.
2013-09-14 10:21:09,674 [ERROR] Unhandled Error
Traceback (most recent call last):
  File "/usr/local/lib/python2.7/dist-packages/obfsproxy-0.2.2_9_g37c9cbe-py2.7.egg/obfsproxy/pyobfsproxy.py", line 69, in do_managed_mode
    managed_server.do_managed_server()
  File "/usr/local/lib/python2.7/dist-packages/obfsproxy-0.2.2_9_g37c9cbe-py2.7.egg/obfsproxy/managed/server.py", line 60, in do_managed_server 
    reactor.run()
  File "/usr/lib/python2.7/dist-packages/twisted/internet/base.py", line 1192, in run
    self.mainLoop()
  File "/usr/lib/python2.7/dist-packages/twisted/internet/base.py", line 1201, in mainLoop
    self.runUntilCurrent()
--- <exception caught here> ---
  File "/usr/lib/python2.7/dist-packages/twisted/internet/base.py", line 797, in runUntilCurrent
    f(*a, **kw)
  File "/usr/lib/python2.7/dist-packages/twisted/internet/base.py", line 580, in stop
    "Can't stop reactor that isn't running.")
twisted.internet.error.ReactorNotRunning: Can't stop reactor that isn't running.

2013-09-14 10:21:09,674 [DEBUG] conn_0x7f4e0e213890: Connection was lost (Connection to the other side was lost in a non-clean fashion: Connection lost.).
2013-09-14 10:21:09,674 [DEBUG] conn_0x7f4e0e213890: Closing connection.
2013-09-14 10:21:09,675 [DEBUG] circ_0x7f4e0e2165f0: Tearing down circuit.
2013-09-14 10:21:09,675 [DEBUG] conn_0x7f4e0e20bb50: Closing connection.
2013-09-14 10:21:09,675 [DEBUG] conn_0x7f4e0e20bbd0: Connection was lost (Connection to the other side was lost in a non-clean fashion: Connection lost.).
2013-09-14 10:21:09,675 [DEBUG] conn_0x7f4e0e20bbd0: Closing connection.
2013-09-14 10:21:09,675 [DEBUG] circ_0x7f4e0e216d40: Tearing down circuit.
2013-09-14 10:21:09,675 [DEBUG] conn_0x7f4e0e20b8d0: Closing connection.
2013-09-14 10:21:09,676 [DEBUG] conn_0x7f4e0e20b8d0: Connection was lost (Connection to the other side was lost in a non-clean fashion: Connection lost.).
2013-09-14 10:21:09,676 [INFO] Stopping factory <obfsproxy.network.network.StaticDestinationClientFactory instance at 0x7f4e0e216d88>
2013-09-14 10:21:09,676 [DEBUG] conn_0x7f4e0e20bb50: Connection was lost (Connection to the other side was lost in a non-clean fashion: Connection lost.).
2013-09-14 10:21:09,676 [INFO] Stopping factory <obfsproxy.network.network.StaticDestinationClientFactory instance at 0x7f4e0e216638>
2013-09-14 10:21:09,677 [INFO] (TCP Port 50126 Closed)
2013-09-14 10:21:09,677 [INFO] Stopping factory <obfsproxy.network.network.StaticDestinationServerFactory instance at 0x7f4e0e2163b0>
2013-09-14 10:21:09,678 [INFO] Main loop terminated.

I noticed this while testing the super-proxy from #7167 (moved); it tries to SIGINT its subprocesses when it gets a SIGINT, and obfsproxy is killing existing connections when that happens.

May also need to handle SIGTERM à la #9732 (moved).