I set up an openvpn client on Ubuntu 18.04 by creating a work.conf file under /etc/openvpn/

I start it with:

sudo systemctl start openvpn@work.service

When I stop it,

sudo systemctl stop  openvpn@work.service

it hangs for exactly 90 seconds before finally shutting down. Checking the logs shows the graceful shutdown timing out, at which point a SIGKILL is issued:

journalctl -n 6 -u openvpn@work.service

12:59:51 systemd[1]: Stopping OpenVPN connection to work...
13:01:21 systemd[1]: openvpn@work.service: State 'stop-sigterm' timed out. Killing.
13:01:21 systemd[1]: openvpn@work.service: Killing process 12379 (openvpn) with signal SIGKILL.
13:01:21 systemd[1]: openvpn@work.service: Main process exited, code=killed, status=9/KILL
13:01:21 systemd[1]: openvpn@work.service: Failed with result 'timeout'.
13:01:21 systemd[1]: Stopped OpenVPN connection to work.

I've noticed a bunch of sleeping openvpn processes, some many days old:

ps ax -o command | grep --count '[o]penvpn'

ps ax -o stat,start,command | grep '[S]TAT\|[o]penvpn'
S     Aug 21  /bin/bash /etc/openvpn/update-resolv-conf tun0 1500 1553 ... ... init
S     Aug 21  run-parts --arg=-a --arg=tun0.openvpn /etc/resolvconf/update.d

I see a lot of similar processes in the service's cgroup:

systemd-cgls -u openvpn@work.service | grep --count run-parts
systemd-cgls -u openvpn@work.service | grep --count update-resolv-conf

I've also noticed that there is an openvpn.service in addition to my openvpn@work.service. I'm not clear on the interaction between the two. I think my @work service is grouped under the other service, but not sure.

I'd like to figure out why the service fails to shutdown cleanly, and how/whether to clean up all those proceses that appear to be duplicates. What would you suggest as a next step?

I can post my conf file if that's useful...


I ran into a similar/same problem. Timeout when I wanted to stop the OpenVPN service...

It turned out that my update-resolv-conf file was the problem.

I suggest to comment out the up / down update-resolv-conf lines in your work.conf and check if the behaviour changes. Especially, as the processes seem to stay alive...


  • Did you find a replacement for update-resolv-conf or does your setup not involve any DNS config changes (i.e. using a different name-server when on the VPN than when off the VPN)? – ivan Oct 27 '18 at 14:55
  • Previously I tried to use dnsmasq as local DNS proxy. However, it turned out to be a bad idea in conjunction with OpenVPN. I tried to restart the dnsmasq daemon after getting the new DNS servers from the OpenVPN conneciton within update-resolv-conf. Worked let's say sporadically. I disable and enable dnsmasq now with a little shell script work-around. – tobiasweede Nov 4 '18 at 8:50

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.