This is what 180-pluggable-transport.txt says about proxies and SIGINT:
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.
I implemented the websocket-server transport to do this. https://gitweb.torproject.org/flashproxy.git/blob/c23caf1f71f8281319cadf5500... I noticed unexpected behavior when the proxy receives a SIGINT, and doesn't have any open connection, and so exits immediately without waiting for a second SIGINT. The parent tor process tries to kill a nonexistent PID:
^CApr 19 17:58:59.000 [notice] Interrupt: we have stopped accepting new connections, and will shut down in 30 seconds. Interrupt again to exit now. ^CApr 19 17:59:05.000 [notice] SIGINT received a second time; exiting now. Apr 19 17:59:05.000 [notice] Failed to terminate process with PID '18277' ('No such process').
Is this intended? It seems the PID might have been reclaimed in the meantime, and tor could be killing an unrelated process. I can think of two changes that would make it seem to me to work more naturally. The first is for tor to poll the child PID to see if it has exited before killing it; this reduces the race window. The other is to require proxies always to wait until their second SIGINT before quitting. (Concretely in the websocket-server example, remove the"numHandlers != 0" condition from the second sigint loop.)
David Fifield