One OpenVPN drop-in changed every tunnel: instance vs template

A restart policy added for one tunnel starts applying to every tunnel on the machine. That is not a systemd bug; it is the difference between an instance drop-in and a template drop-in. The path you write the file under decides how many services inherit it.

Choose the scope before the setting. The two directories look almost identical, and only one of them is limited to the instance you meant.

The symptom: one edit, every tunnel

An instance-specific drop-in lives under a directory named for the full instance, such as [email protected]. A template drop-in lives under [email protected], with the at-sign and no instance name between them. The first applies to office only. The second applies to every service instantiated from that template.

The template form does not reach a separate [email protected] template, and it does not reach unrelated services with openvpn in the name.

Pick the directory that matches the scope

Both directories sit under /etc/systemd/system/. Dropping the final system component creates a path systemd does not read as a system override, which is a quiet way to make a correct-looking file do nothing. Write the full path once and reuse it.

A drop-in also needs the right section header. Service settings belong under [Service]. A file with settings but no section is ignored or rejected, and the unit keeps behaving as before while the file sits there looking authoritative.

Keep the purpose in the file name if you add more than one drop-in. Lexicographic order decides the merge, and a name that says what the file does makes that order readable.

Read the merged unit before writing

Read the merged unit before writing anything. systemctl cat [email protected] prints the main unit and every drop-in that applies, in merge order. Compare it with a second instance when you are considering a template change. That comparison shows exactly which services would inherit the edit.

An instance file does not erase template settings. Both are merged, so a template value you forgot about can still be in force.

Other named drop-ins, runtime settings and package-supplied configuration also participate. Do not assume the file you edited last is the whole unit. The merged output is the unit.

Keep unit policy out of the profile

Keep unit policy and VPN configuration separate. A profile directive does not become valid systemd syntax because it sits under [Service]. A restart setting does not belong in an .ovpn file either.

That separation is also why a restart policy is not the same thing as OpenVPN's own peer recovery. Decide which behaviour you want before choosing a scope.

Apply it and verify the instance

After the change, reload the manager's definitions with systemctl daemon-reload. That reload does not restart the tunnel; it only re-reads unit files. Then apply the lifecycle action you intended to the exact instance.

Verify by reading the loaded unit again and by watching the behaviour you changed. A restart that carries active work deserves a planned interruption, not a quick test on a production tunnel. Record the override's purpose and scope next to the deployment so the next person knows whether the file was meant to be shared.

If the policy really is shared, move it to the template deliberately and check a second instance before calling it done. The systemd unit reference documents drop-in precedence and merge order.