Something keeps starting an OpenVPN unit: find the source

An OpenVPN instance comes up at boot under a name you do not recognise, and stopping it works until the next reboot. That pattern means you have removed the process but not the activation. The two are different objects, and only one of them is visible in a status screen. Finding the activation takes four read-only commands and one decision.

Name the exact unit first

Work from the unit name in the journal rather than from a profile filename. The instance may be called openvpn@, openvpn-client@, openvpn-server@ or something distribution-specific, and guessing the name sends you to the wrong template. The status output names the unit that actually ran, which is the only name that matters here. Copy it exactly, including any suffix.

The following commands describe that unit without changing anything. systemctl show reports the fragment path, the source path, the unit file state, any drop-ins and what triggered it. list-dependencies --reverse shows which loaded units point at it. Both are read-only, so run them before forming a theory.

Substitute the observed name everywhere. A copy-pasted example name is the most common way to investigate the wrong service, and it produces confident answers about a unit that never ran.

Read the template to learn the file name

An instance unit is an expansion of a template, and the template decides which configuration file it reads. A command line ending in a per-instance placeholder resolves to the instance name plus the suffix. If the suffix is .conf and the instance is called old, the file is old.conf. Name the instance old.conf and the same template asks for old.conf.conf.

That detail explains a class of duplicates. Someone adds a second instance under the wrong name, the first keeps running, and the host ends up with two tunnels and one confusing log.

Read the effective template rather than the file you remember editing. A drop-in can replace the command line, and the replacement is what runs at boot.

Trace how it enters the boot transaction

Three routes are common: a wants link from a target, a requirement from another unit, or a generated unit produced by a package generator. The reverse-dependency listing covers the first two as loaded graph entries. It does not cover a timer, a hook or an external request, which is why the listing is evidence rather than a complete audit.

Generated output under /run/systemd/generator is a product, not a source. Editing it survives only until the next generation, which is why a fix applied there looks successful and then reverts.

Check the package's documented input before assuming where the generator reads from. An undocumented scan of a directory is the usual reason a unit appears without an enablement link.

Remove the activation, not just the process

If the instance is directly enabled and genuinely obsolete, systemctl disable --now stops it and removes the boot link in one step. Check first that this tunnel is not your only administrative path to the host. The command is a lifecycle example, not a suggestion to stop every VPN on the machine. Run the check before the command, not after.

The two halves are separable and often confused. Disabling does not stop a running service, and stopping does not remove enablement, so a partial command explains a problem that returns at boot.

A disabled unit can still be started by another unit or by an explicit request. When a generator owns activation, fix the generator input instead of disabling its output. Masking blocks more paths but can break dependencies, so it is not a substitute for understanding.

Verify with a reboot, not a status screen

Reload systemd if unit definitions or generator inputs changed, then inspect the resulting state. A daemon reload does not push a new profile into a running tunnel, so the two checks are separate. Schedule a reboot and confirm the instance stays absent while the intended tunnel still works.

Keep the old profile until its ownership is understood, then retire it through the intended process. Success is an absent unit and a working access path, not a failed unit missing from one screen.