OpenVPN DNS left behind after SIGKILL: check the owner first

DNS stops resolving after an OpenVPN client is killed, and the first instinct is to rewrite /etc/resolv.conf. That edit can break a working resolver while the real stale state sits somewhere else. The question to settle first is who owns the DNS settings the tunnel installed, and whether the exit that skipped cleanup actually mattered.

Three conditions decide the repair: the signal that ended the process, the resolver component that received the settings, and whether the tunnel link still exists. Answer them in that order and the fix usually follows without touching a global file.

Decide what kind of exit happened

In Community OpenVPN, SIGINT and SIGTERM are both graceful exit requests. SIGKILL is uncatchable: it cannot be blocked or handled, so no shutdown routine gets a chance to run. A normal Ctrl+C in a foreground terminal generates SIGINT, while a supervisor that gives up waiting usually escalates to SIGKILL. The difference matters because only the second case guarantees the hooks were skipped.

Running inside screen or tmux does not change which signal Ctrl+C sends. Check what the process actually received rather than what the terminal normally does.

When a service or connection manager runs the tunnel, stop that one connection through its owner rather than killing the pid. A manager may bring the process back up, leaving you with a fresh tunnel and confusing resolver state. A standalone process only needs an ordinary termination request for cleanup to run.

Decide who owns the resolver

systemd-resolved, a resolvconf-style script and a plain file rewrite are three different owners. The first keeps per-link settings in memory and drops them when the interface disappears. The second keeps records that persist until something removes them. The third writes a file and leaves restoration to whoever wrote it.

Identify the owner before choosing a repair command. The same symptom has three different correct answers depending on which one is in use.

A NetworkManager-managed VPN may already own resolver changes. Adding a second helper on top creates two owners competing over the same link, and the loser's state reappears at the next reconnect. If a manager is in charge, fix the setting in the manager rather than in a script.

What the down hook can and cannot do

The down script runs once the TUN/TAP device has closed. Adding down-pre flips that order and runs the script while the device still exists, which helpers that need the live link require.

Neither directive makes a hook run after SIGKILL. Privileges are also not restored by down-pre: if the daemon drops to a user or group or enters a chroot, the hook runs with whatever access that leaves it. An invoked hook can still fail to update the resolver. The OpenVPN reference covers the signals and the callback lifecycle.

Check the hook's own error next to the process exit status. A missing cleanup and a failed cleanup look the same in the resolver and different in the logs.

Check the state that actually remains

On a system using systemd-resolved, resolvectl status shows which link still carries the VPN DNS servers or routing domains. That link may belong to a connection that is gone, or to another tunnel that is still up.

An interface that disappears takes its per-link configuration with it, so a skipped hook can coexist with clean DNS. If the link is still registered and exclusively owned by the stopped connection, the owning manager should remove it. If an older script rewrote a global resolver file, look for that script's documented restore step instead.

Recover without stealing another link

When per-link settings are yours to manage, resolvectl revert takes the link name and clears the runtime DNS configuration for that interface. It is a runtime action rather than a profile edit, so persistent connection configuration stays untouched. Name the wrong link and you clear DNS for a working tunnel, which is why the name comes from the status output.

Confirm /etc/resolv.conf is a managed symlink before editing it, then stop the client normally once more and look at DNS again. If the second stop cleans up, the earlier problem was the forced exit rather than the configuration.