"service openvpn restart" broken. Stop returns before finishing.

Bug #1200519 reported by Avery-yates
20
This bug affects 3 people
Affects Status Importance Assigned to Milestone
openvpn (Debian)
Fix Released
Unknown
openvpn (Ubuntu)
Fix Released
Undecided
Unassigned

Bug Description

When restarting openvpn with "service openvpn restart" this occurs:

Jul 12 09:37:03 Muur2 ovpn-client[3831]: TCP/UDP: Socket bind failed on local address [undef]: Address already in use
Jul 12 09:37:04 Muur2 ovpn-client[3743]: WARNING: Failed running command (--up/--down): external program exited with error status: 255

Failing openvpn services to restart.

Using "Service openvpn start && service openvpn stop" yields the same result.

When doing a "serice openvpn stop" followed by "service openvpn start" in a shell it works.

I presume openvpn returns before making sure the sockets it uses are closed properly or sockets report being closed wrongly.

This is a serious bug . Machines become inaccessible after updates that require openvpn to be restarted.

Thank you for looking into this.

Tags: patch
Revision history for this message
Avery-yates (avery-yates) wrote :

Added Mr Stéphane Grabber to subscriber list since he seems to be involved with most OpenVpn packages on ubuntu so far.

Regards.

Revision history for this message
Avery-yates (avery-yates) wrote :

Edit:
This bug started with the move to openvpn 2.3.2-4ubuntu1 a few hours ago from now.

description: updated
Revision history for this message
Steven Peeters (precies) wrote :

I have the same result on vmware running a VM8 machine with vmxnet3 nic's.

Although something is mentioned in the debian-unstable merge ,
  quote "+ Do not use start-stop-daemon and </dev/null to avoid blocking boot."

Implications go beyond booting. This should probably not have been implemented until this issue was fixed or a reasonable _temporary_ workaround found.

For example a PID for each running openvpn instance could be gotten , then one could loop netstat until no more ports linked to those pid's is open.

In extremis even a few seconds sleep before "stop" returns would probably work.

An actual fix would probably be best , but imo stop gap measures should be implemented before releasing if releasing is primordial.

With this:
Also affected.

Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in openvpn (Ubuntu):
status: New → Confirmed
Revision history for this message
Simon Déziel (sdeziel) wrote :

Avery, in comment #2 you mentioned it started with 2.3.2-4ubuntu1 but I noticed this problematic behavior since at least the version shipped in Precise: 2.2.1-8ubuntu1.1.

The init script sleeps for 1 second between stop and start when asked to restart. As a temporary workaround, sleeping for 3 seconds give it enough time to cleanup after itself.

Revision history for this message
Avery-yates (avery-yates) wrote :

Simon, thank you for taking the time to comment.
I have just now tested this on another identical machine running 12.04. As you said , the issue exists there as well. I must not have encountered it before today.

Still , this caused a part of my network to do down this morning when openvpn had restarted during the update . It didn't cause anything significant beyon,d having to call someone to press the reset button though.

Would it be possible to use another technique to decide when the openvpn service should return except for an arbitrary amount of seconds? ( What the person above here suggested maybe , though i don't really understand what he means exactly) Or maybe add the ability to select the amount of seconds to wait using /etc/default/openvpn or something similar.(which does seem like a plaster on a wooden leg)

In my humble opinion this bug should stay open until a solution beyond "sleep until it has cleaned up after itself" has been found. Whether restarting a service will work should not be at the mercy of such things. It should be guaranteed to always work . If it doesn't it should be fixed.

Friendly regards.
Avery.

Revision history for this message
Avery-yates (avery-yates) wrote :

@ simon
Also , about changing the number of sleep seconds in a restart, that would not fix scripts that stop and start the openvpn service. If as a temporary measure a delay is chosen the delay should be put somewhere in "stop" not in "restart"

Regards.

Revision history for this message
Simon Déziel (sdeziel) wrote :

@Avery, I've put up a little patch for the initscript that removes all sleeps and wait for the PID file to vanish before considering the stop action completed. Since it now uses start-stop-daemon it should be a little bit clever.

It works well with my 4 VPNs here but would appreciate if you could give it a try and provide some feedback here.

Revision history for this message
Avery-yates (avery-yates) wrote :

Works like a charm .

Hoping it gets put in release.

Thank you for the speedy replies.

Revision history for this message
Ubuntu Foundations Team Bug Bot (crichton) wrote :

The attachment "Use start-stop-daemon --retry instead of kill." seems to be a patch. If it isn't, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are a member of the ~ubuntu-reviewers, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issues please contact him.]

tags: added: patch
Revision history for this message
Simon Déziel (sdeziel) wrote :

Thanks for testing Avery. I'll try to open a bug in Debian to hopefully have this fixed at the source. If that goes well, Ubuntu will be next.

Changed in openvpn (Debian):
status: Unknown → New
Changed in openvpn (Debian):
status: New → Fix Committed
Revision history for this message
Avery-yates (avery-yates) wrote :

The fix has a "upload pending" flag attached to it on debian.
It seems to have been accepted but is stuck in the queue.

Adding this comment to make sure it gets added to saucy before final beta, and definitely upon release.

Friendly regards.

Revision history for this message
Avery-yates (avery-yates) wrote :

Still "Upload pending" on debian. making an 2.3.2-4ubuntu2 with the fix included would not be a bad idea at this point imo.
The version that would eventually trickle down from debian would be the same anyway.

Regards.

Changed in openvpn (Debian):
status: Fix Committed → Fix Released
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package openvpn - 2.3.2-7ubuntu3

---------------
openvpn (2.3.2-7ubuntu3) trusty; urgency=medium

  [ Simon Deziel ]
  * Refresh delta with debian/openvpn.init.d:
   - Make stop action reliable by killing if needed
     (LP: #1274254, LP: #1200519)
   - Use new path for status file (LP: #1261088)
 -- Stephane Graber <email address hidden> Tue, 04 Feb 2014 09:31:39 -0500

Changed in openvpn (Ubuntu):
status: Confirmed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.