SIGTERM (soft) lost if followed by a SIGUSR1/SIGHUP restart during the exit-notify wait

[Selva Nair]

When --explicit-exit-notify n is used, a soft SIGTERM triggers exit-notify repeated n times in 1 second intervals, before the signal is really set. During this wait a SIGUSR1 or SIGHUP restart causes the SIGTERM lost. The connection just restarts.

Seen on Linux and Windows.

To reproduce, connect to the management interface and send

signal SIGTERM
signal SIGUSR1

The second command maybe SIGHUP instead, and should be issued before the exit notify triggered by the SIGTERM is completed (using n=2 or larger helps).

Sun Jun  5 14:42:52 2016 us=482865 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:7500
Sun Jun  5 14:42:53 2016 us=905629 MANAGEMENT: CMD 'signal SIGTERM'
Sun Jun  5 14:42:53 2016 us=905710 SIGTERM received, sending exit notification to peer
Sun Jun  5 14:42:54 2016 us=511249 MANAGEMENT: CMD 'signal SIGUSR1'
Sun Jun  5 14:42:54 2016 us=511490 TCP/UDP: Closing socket
Sun Jun  5 14:42:54 2016 us=511533 SIGUSR1[hard,] received, process restarting
Sun Jun  5 14:42:54 2016 us=511559 Restart pause, 5 second(s)
Sun Jun  5 14:42:59 2016 us=527109 Re-using SSL/TLS context
Sun Jun  5 14:42:59 2016 us=527230 Control Channel MTU parms [ L:1557 D:1184 EF:66 EB:0 ET:0 EL:3 ]
..
..
Sun Jun  5 14:43:04 2016 us=110261 Initialization Sequence Completed

Except for the explicit-exit-notify, the client is a vanilla tls-client:

client
dev tun
ping 30
ping-restart 120
remote test-server 1194
resolv-retry infinite
nobind
persist-tun
persist-key
user nobody
group nobody
ca test-ca.crt
cert test-client.crt
key keys/test-client.key
ns-cert-type server
tls-auth keys/test-ta.key 1
cipher AES-256-CBC
explicit-exit-notify 2
management localhost 7500
nice 3
verb 4

[Gert Döring]

cc'ing plaisthos as he has fought with the signal handling when reworking the getaddrinfo() stuff, so maybe he has an idea.

My gut says "we might want prioritize pending signals, so a SIGTERM will always override SIGUSR1 or SIGHUP" - but I'm not sure I fully understand our signal handling, and whether there is an existing use case for "the second signal overrides the first signal, no matter which combinations".

[Gert Döring]

Just as a reference - commit 63b3e000c9141f4ca03a374354da26334257bc18 references this ticket and fixes the most visible SIGUSR1/SIGHUP <-> SIGTERM interactions (while in exit notification), but not the general case.