Opened 10 years ago

Closed 5 years ago

Last modified 5 years ago

#394 closed Feature Wish (fixed)

OpenVPN GUI shouldn't (always) error when already running

Reported by: tlhackque Owned by: Heiko Hund
Priority: minor Milestone:
Component: Windows GUI Version: OpenVPN 2.3.2 (Community Ed)
Severity: Not set (select this one, unless your'e a OpenVPN developer) Keywords:
Cc:

Description

For windows, I have an installer that installs a config file and creates a desktop shortcut for "Connect to fooService". The target is "C:\Program Files\OpenVPN\bin\openvpn-gui --connect fooService.ovpn".

If openvpn-gui is not running, activating the shortcut does what's expected: starts the GUI and the GUI starts the tunnel.

If the user disconnects the tunnel, openvpn-gui does not exit. (OK)

Now, activating the shortcut results in "OpenVPN GUI is already running" as a pop-up error window.

This is not a good user experience. The user doesn't care that the GUI is running; the tunnel is not, and he wants it activated.

The second instance should simply pass the 'connect' command to the first instance and exit. Then the first instance can connect (or say 'already connected to ...').

I think this is a bug because the current behavior violates the principle of least surprise - though I suppose some might call it a feature request.

This has been experienced on XP SP3, though I would expect other versions to behave the same way.

Change History (6)

comment:1 Changed 10 years ago by Gert Döring

Owner: set to Heiko Hund
Status: newassigned

Heiko, any idea how complicated this would be to teach to the Gui?

comment:2 Changed 8 years ago by Selva Nair

I have a branch that does this here github

If there is interest I can make a patch.

Version 0, edited 8 years ago by Selva Nair (next)

comment:3 Changed 8 years ago by biggsy

I agree that this behavior does not give a good user experience.

Looking at the age of the comments above, I thought there may have been some workaround but I can't find anything.

As it shouldn't impact existing use cases, is there any prospect of the fix being merged?


comment:4 Changed 8 years ago by Selva Nair

Its not really clear to me what behaviour would be preferred in various scenarios: E.g., no --connect option is used and an instance is already running but (i) no connections active (ii) many connections active. Or the new instance has a different --connect option than the already running instance.

Never got any feedback on the feature branch I referred to in the earlier comment either.​ Here is a link to the relevant commit in my private repo github

The approach in the above commit is to start auto-connect configs if any or show the already-running message as before.

comment:5 Changed 5 years ago by Selva Nair

Priority: majorminor
Resolution: fixed
Status: assignedclosed
Type: Bug / DefectFeature Wish

This was addressed in PR 188 (in release 2.4.5, GUI version 11.10.0) that enhanced and improved handling of starting a second instance of the GUI.

comment:6 Changed 5 years ago by biggsy

Thank you very much for this, selvanair.

I have only tested it for 5 minutes but it appears to work very well.

Note: See TracTickets for help on using tickets.