apt purge removeu a VPN, mas o serviço ainda arranca no boot

apt purge diz que o pacote não está mais lá, e mesmo assim um túnel volta a subir a cada arranque. O journal continua a crescer, as rotas regressam, e a máquina comporta-se como se nada tivesse sido removido. O instalador do fornecedor pode escrever arquivos que o gestor de pacotes nunca registou, por isso desinstalar um pacote e desinstalar um produto são tarefas diferentes. O runbook abaixo separa os dois registos e termina a remoção de propósito.

Dois instaladores, dois registos diferentes

Os pacotes Debian mantêm uma lista de arquivos, e uma purge apaga exatamente o que essa lista nomeia mais a configuração do pacote. Um instalador shell ou um pacote .run não mantém essa lista; escreve onde quer, normalmente em /opt, /usr/local e /etc/systemd/system. Nenhum desses caminhos aparece na lista de arquivos de qualquer pacote, portanto o dpkg nem os conhece nem os reporta. Acaba com dois donos da instalação num só sistema de arquivos e apenas um deles faz contabilidade.

Pergunte ao dpkg pelo caminho concreto antes de o apagar. Um caminho que ele renega é seu para remover, e a mesma resposta diz se uma atualização posterior o devolveria.

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

Uma unidade e o seu link wants são arquivos separados

Ativar é um ato separado de instalar. A unidade declara relações de destino na sua secção [Install], e systemctl enable transforma essas declarações em links simbólicos dentro do diretório .wants/ de cada destino. Passam a existir dois caminhos: o arquivo da unidade e o link que a arrasta para um destino de arranque. Apague só o arquivo e o link aponta para o nada, o que produz uma queixa no arranque; apague só o link e a unidade continua a poder ser iniciada pelo nome. Ambos têm de desaparecer.

Remova-os por ordem e recarregue depois, para que o systemd deixe de guardar as definições antigas em memória.

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

Leia FragmentPath em vez de assumir a localização, pois o fornecedor pode ter escrito em /usr/lib/systemd/system ou /lib/systemd/system em vez de /etc. Apagar a cópia que esperava deixa a efetiva a correr, e a correção parece bem-sucedida até ao próximo recarregamento. Liste novamente os arquivos das unidades quando o recarregamento terminar, e confirme que o nome já não aparece.

Encontre o binário que mantém a disposição viva

Uma unidade ativada continua a iniciar o daemon, creia o que crer a base de dados de pacotes. Esse processo pode trazer o túnel de volta, voltar a acrescentar rotas ou restaurar uma regra de kill-switch, e o comportamento parece sobrenatural até inspecionar a disposição. Siga o caminho de ExecStart e verifique se o binário ainda lá está, porque um executável deixado em /opt é tudo o que a disposição precisa. Apagar a unidade trava o arranque agendado; não apaga o programa.

Trate os diretórios de estado com o mesmo cuidado. Os tokens de conta, os perfis gerados e as listas de servidores em cache vivem em /var/lib ou num diretório pessoal, e são credenciais, não cache descartável. Remova-os depois de parar o serviço, deliberadamente, e anote o que levou.

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

Escolha um único dono do arranque e teste-o

Três candidatos podem reclamar o arranque, e instalar os três produz uma corrida em vez de uma dupla segurança. Um arquivo de autostart do ambiente de trabalho só corre depois de alguém iniciar sessão, uma unidade systemd corre mais cedo mas exige um cliente que funcione sem ecrã, e uma entrada cron @reboot dispara segundo um horário que pode estar errado para um cliente de rede. A CLI do fornecedor pode ainda exigir um argumento de servidor, porque no arranque não há sessão anterior para retomar. Escolha o candidato que corresponde à forma como o cliente se autentica, e descarte os outros.

Teste-o reiniciando a máquina e olhando para três factos independentes: o estado da unidade, a lista de processos e uma nova ligação a algo que possa verificar. Um cliente que exige um porta-chaves ou um início de sessão interativo falha no arranque mesmo com um arquivo de unidade correto, e o journal di-lo se o ler em vez de apenas o estado do serviço.

Ou dê ao cliente uma credencial que funcione sem pedir nada, ou arranque-o no início de sessão. Ambas são defensáveis, e combiná-las é como um túnel acaba com dois donos que lutam por ele.

Anote o que o próximo purge deve esperar

Anote dois factos após qualquer remoção manual: que instalador criou a disposição e que dono a arranca agora. Essa nota transforma o próximo purge de surpresa em ponto de uma lista de verificação, e sobrevive à pessoa que fez o trabalho.

Guarde-a junto da configuração do serviço e não num diretório pessoal, e ponha-lhe data, porque uma atualização do fornecedor pode restaurar uma unidade que apagou. Comparar systemctl list-unit-files com essa nota a cada poucos meses apanha a restauração enquanto a correção ainda é barata.