[tor-dev] Behavior of pluggable transport proxies on SIGINT

[David Fifield <david@xxxxxxxxxxxxxxx>]

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/c23caf1f71f8281319cadf55002723dbcd333905:/websocket-transport/websocket-server.go#l238
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
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev