#824 closed Bug / Defect (duplicate)
with proto tcp-server sd_notify not sent to systemd until client connects
Reported by: | DonJaime | Owned by: | |
---|---|---|---|
Priority: | major | Milestone: | |
Component: | Generic / unclassified | Version: | OpenVPN 2.4.0 (Community Ed) |
Severity: | Not set (select this one, unless your'e a OpenVPN developer) | Keywords: | tcp sd_notify systemd |
Cc: |
Description
I have a systemd service running to provide a server on a tcp port. It worked up until version 2.3.14. Since update to 2.4.0 the service startup fails with a timeout, unless a client connects quickly enough.
systemctl status after failed startup:
● openvpn-server@tcp.service - OpenVPN service for tcp Loaded: loaded (/usr/lib/systemd/system/openvpn-server@.service; enabled; vendor preset: disabled) Active: failed (Result: timeout) since Wed 2017-01-18 11:00:43 CET; 43min ago Docs: man:openvpn(8) https://community.openvpn.net/openvpn/wiki/Openvpn24ManPage https://community.openvpn.net/openvpn/wiki/HOWTO Process: 28791 ExecStart=/usr/sbin/openvpn --status %t/openvpn-server/status-%i.log --status-version 2 --suppress-timestamps --config %i.conf (code=exit Main PID: 28791 (code=exited, status=0/SUCCESS) Jan 18 10:59:13 pi openvpn[28791]: Listening for incoming TCP connection on [AF_INET][undef]:1194 Jan 18 11:00:43 pi systemd[1]: openvpn-server@tcp.service: Start operation timed out. Terminating. Jan 18 11:00:43 pi openvpn[28791]: GID set to nobody Jan 18 11:00:43 pi openvpn[28791]: UID set to nobody Jan 18 11:00:43 pi openvpn[28791]: /usr/bin/ip addr del dev tun1 local 192.168.1.1 peer 192.168.1.5 Jan 18 11:00:43 pi openvpn[28791]: Linux ip addr del failed: external program did not exit normally Jan 18 11:00:43 pi openvpn[28791]: SIGTERM[hard,init_instance] received, process exiting Jan 18 11:00:43 pi systemd[1]: Failed to start OpenVPN service for tcp. Jan 18 11:00:43 pi systemd[1]: openvpn-server@tcp.service: Unit entered failed state. Jan 18 11:00:43 pi systemd[1]: openvpn-server@tcp.service: Failed with result 'timeout'.
systemclt status output after rapid client connection:
# systemctl status openvpn-server@tcp # client connection established quickly ● openvpn-server@tcp.service - OpenVPN service for tcp Loaded: loaded (/usr/lib/systemd/system/openvpn-server@.service; enabled; vendor preset: disabled) Active: active (running) since Wed 2017-01-18 11:44:46 CET; 15min ago Docs: man:openvpn(8) https://community.openvpn.net/openvpn/wiki/Openvpn24ManPage https://community.openvpn.net/openvpn/wiki/HOWTO Main PID: 28825 (openvpn) Status: "Initialization Sequence Completed" CGroup: /system.slice/system-openvpn\x2dserver.slice/openvpn-server@tcp.service └─28825 /usr/sbin/openvpn --status /run/openvpn-server/status-tcp.log --status-version 2 --suppress-timestamps --config tcp.conf Jan 18 11:44:46 pi openvpn[28825]: GID set to nobody Jan 18 11:44:46 pi openvpn[28825]: UID set to nobody Jan 18 11:44:46 pi openvpn[28825]: Peer Connection Initiated with [AF_INET]127.0.0.1:42554 Jan 18 11:44:47 pi openvpn[28825]: Initialization Sequence Completed Jan 18 11:47:57 pi openvpn[28825]: Connection reset, restarting [0] Jan 18 11:47:57 pi openvpn[28825]: SIGUSR1[soft,connection-reset] received, process restarting Jan 18 11:47:58 pi openvpn[28825]: Re-using pre-shared static key Jan 18 11:47:58 pi openvpn[28825]: Preserving previous TUN/TAP instance: tun1 Jan 18 11:47:58 pi openvpn[28825]: Could not determine IPv4/IPv6 protocol. Using AF_INET Jan 18 11:47:58 pi openvpn[28825]: Listening for incoming TCP connection on [AF_INET][undef]:1194
# /etc/openvpn/server/tcp.conf proto tcp-server # udp is best and default, but socks fails ifconfig 192.168.1.1 192.168.1.5 # local / remote secret /etc/openvpn/home.key persist-key float # let remote ip change dev tun persist-tun tun-mtu 1500 comp-lzo # use compression #tun-ipv6 # doesn't currently work verb 1 # 1 = not very verbose mute-replay-warnings # avoid gazillions of warnings on wifi keepalive 10 120 ping-timer-rem cipher AES-128-CBC user nobody # be this after initialisation group nobody
Change History (4)
comment:1 Changed 7 years ago by
comment:2 Changed 7 years ago by
Resolution: | → duplicate |
---|---|
Status: | new → closed |
comment:3 Changed 7 years ago by
thanks, eworm, for spotting the duplicate one, saves me the searching :-)
comment:4 Changed 7 years ago by
It may be the same bug, but that's not clear either from the description or from the comments to the code in the patch to fix it, which refer to non-TLS mode. Non-TLS mode works fine with a UDP port; the problem only arises with tcp.
Note: See
TracTickets for help on using
tickets.
This is a duplicate of #801.