apt purge Removed the VPN but the Service Still Starts at Boot

apt purge says the package is gone, and yet a tunnel still comes up at every start. The journal keeps growing, routes come back, and the machine behaves as if nothing had been removed. A vendor installer can write files that the package manager never recorded, so uninstalling a package and uninstalling a product are different jobs. The runbook below separates the two records and finishes the removal on purpose.

Two installers, two different records

Debian packages keep a file list, and a purge deletes exactly what that list names plus the package configuration. A shell installer or a .run bundle keeps no such list; it writes where it likes, commonly into /opt, /usr/local and /etc/systemd/system. None of those paths appear in any package file list, so dpkg neither knows about them nor reports them. You end up with two installation owners on one filesystem and only one of them keeping books.

Ask dpkg about the specific path before deleting it. A path it disowns is yours to remove, and the same answer tells you whether a later upgrade would put it back.

dpkg -S /etc/systemd/system/acmevpn.service
systemctl list-unit-files | grep -i acmevpn

A unit and its wants link are separate files

Enabling is a separate act from installing. The unit declares target relationships in its [Install] section, and systemctl enable turns those declarations into symlinks inside each target .wants/ directory. Two paths now exist: the unit file, and the link that pulls it into a boot target. Delete only the file and the link points at nothing, which produces a complaint at boot; delete only the link and the unit stays startable by name. Both have to go.

Remove them in order and reload afterwards, so systemd stops holding the old definitions in memory.

systemctl disable --now acmevpn.service
systemctl show -p FragmentPath -p ExecStart acmevpn.service
sudo rm /etc/systemd/system/acmevpn.service
sudo rm /etc/systemd/system/multi-user.target.wants/acmevpn.service
systemctl daemon-reload

Read FragmentPath instead of assuming the location, since a vendor may have written to /usr/lib/systemd/system or /lib/systemd/system rather than /etc. Deleting the copy you expected leaves the effective one running, and the fix looks successful until the next reload. List the unit files again once the reload finishes, and confirm the name no longer appears.

Find the binary that keeps the arrangement alive

An enabled unit keeps starting the daemon whatever the package database believes. That process can bring the tunnel back up, re-add routes, or restore a kill-switch rule, and the behaviour looks supernatural until you inspect the layout. Follow the ExecStart path and check whether the binary is still there, because an executable left under /opt is all the arrangement needs. Deleting the unit stops the scheduled start; it does not delete the program.

Treat state directories with the same care. Account tokens, generated profiles and cached server lists live under /var/lib or in a home directory, and those are credentials rather than throwaway cache. Remove them once the service is stopped, deliberately, and note what you took.

sudo ls -l /opt/acmevpn /usr/local/bin/acmevpn
sudo find /var/lib -maxdepth 2 -iname "*acme*"
systemctl is-enabled acmevpn.service

Choose one boot owner and test it

Three candidates can claim the boot, and installing all three produces a race rather than belt and braces. A desktop autostart file only runs after someone signs in, a systemd unit runs earlier but needs a client that works headless, and a cron @reboot entry fires on a schedule that may be wrong for a network client. A provider CLI may additionally require a server argument, because at boot there is no previous session to resume. Choose the candidate that matches how the client authenticates, and drop the others.

Test it by rebooting the machine and looking at three independent facts: the unit state, the process list, and a new connection to something you can verify. A client that needs a keyring or an interactive login fails at boot even with a correct unit file, and the journal says so if you read it rather than only the service status.

Either give the client a credential that works without a prompt, or start it at sign-in instead. Both are defensible, and combining them is how one tunnel acquires two owners that fight over it.

Write down what the next purge should expect

Note two facts after any manual removal: which installer created the arrangement, and which owner now starts it. That note converts the next purge from a surprise into a checklist item, and it outlives the person who did the work.

Keep it beside the service configuration rather than in a personal directory, and date it, because a vendor update can restore a unit you deleted. Comparing systemctl list-unit-files against that note every few months catches the restoration while it is still cheap to fix.