with proto tcp-server sd_notify not sent to systemd until client connects

[DonJaime]

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

[eworm]

This is a duplicate of #801.

[Gert Döring]

thanks, eworm, for spotting the duplicate one, saves me the searching :-)

[DonJaime]

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.