Opened 8 years ago
Last modified 8 years ago
#687 new Bug / Defect
SIGTERM (soft) lost if followed by a SIGUSR1/SIGHUP restart during the exit-notify wait
Reported by: | Selva Nair | Owned by: | |
---|---|---|---|
Priority: | major | Milestone: | |
Component: | Generic / unclassified | Version: | OpenVPN git master branch (Community Ed) |
Severity: | Not set (select this one, unless your'e a OpenVPN developer) | Keywords: | |
Cc: | plaisthos |
Description
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
Change History (2)
comment:1 Changed 8 years ago by
Cc: | plaisthos added |
---|
comment:2 Changed 8 years ago by
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.
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".