Which openvpn Binary Is Running? Check the Launch Path

An old workaround moved the OpenVPN executable somewhere else and left a shell wrapper at the original path. Months later, an upgrade lands, and undoing the workaround turns into a guessing game about which file is really the client. The command name, the service's configured executable and the package's own file inventory can all point at different objects, and repairing one of them without the others produces a host that looks fixed and behaves worse.

Start with the path the service launches

A terminal and a systemd unit do not resolve executables the same way. The shell searches a PATH; the unit names a path, and drop-in overrides can replace it without touching the file you are reading. That difference explains most of the confusion in this task. It also decides which file your repair has to target.

Ask the unit what it runs, including the drop-ins that modify it, and read the resulting ExecStart line rather than the fragment you assume is authoritative. Then follow that path through any symbolic link to the final file. A wrapper that ends with an exec into a hidden directory is a common arrangement from these old fixes.

Write the resolved path down before you change anything.

systemctl cat [email protected] | grep -n 'ExecStart'
readlink -f "$(command -v openvpn)"

Compare the command name with the service path

The two answers are frequently different, and that difference is not automatically a fault. A NetworkManager plugin may launch its own path, and a container may mount yet another.

What matters is knowing which owner launches the process that serves traffic. If the unit runs /usr/local/sbin/openvpn-wrapper while your shell resolves /usr/sbin/openvpn, fixing the second file changes nothing about the service.

Ask which package owns each candidate, then decide whether the file is package-managed or locally placed. A file with no owning package is a file someone put there deliberately, and it deserves a name, an owner and a reason before it is deleted. The reverse mistake is also common: overwriting a package file with an old saved binary because a forum post used the same directory.

Let the package database speak for package files

Where the software came from a Debian package, the package database can tell you whether its files still match what was installed. That is a narrow integrity question, not a security verdict, and the difference matters when you decide what to repair. A mismatch means the file changed after installation, which could be your old workaround or a legitimate local edit. The output does not settle which, so read it as a pointer rather than a conclusion.

Run the verification and read the output rather than treating an empty result as proof of anything.

dpkg -S /usr/sbin/openvpn
dpkg --verify openvpn

The dpkg manual documents that verification compares installed files with locally recorded metadata, using stored checksums where present. It notices a changed package file, and it cannot tell you whether some other binary is being launched instead.

Record the state before you repair

Collect the resolved launch path, the file's package relationship, the wrapper's location and the change record that introduced it. Copy the wrapper somewhere protected if it contains integration work that will be needed later.

Do not paste wrapper contents into a support thread before reading them, since these scripts sometimes carry credentials or gateway details.

Record which profiles the service uses and who is connected while you work, because restarting the tunnel may interrupt the session you are using to administer the host.

Verify the launch, then retire the wrapper

After the repair, start the service and confirm the process is running the path you intended. A version query executed by hand proves the file works; it does not prove the unit uses it.

Then reconnect a client and check that the profile still authenticates, because a binary swap that ignores the original options will fail in a way that looks like a certificate problem.

Retire the displaced wrapper through the same change record that introduced it. The finished repair states which executable runs, why, and which file was removed; restoring a filename and hoping is not the same thing.