Algo continua a iniciar uma unidade do OpenVPN: encontre a origem
Desativar uma unidade não é o mesmo que remover a sua ativação. Leia a instância, o mapeamento do modelo e as dependências inversas antes de apagar um perfil.
Uma instância do OpenVPN aparece no arranque com um nome que não reconhece, e detê-la funciona até ao próximo reinício. Esse padrão significa que removeu o processo mas não a ativação. São dois objetos diferentes, e apenas um deles é visível num ecrã de estado. Encontrar a ativação exige quatro comandos só de leitura e uma decisão.
Nomeie primeiro a unidade exata
Trabalhe a partir do nome da unidade no journal, em vez do nome de um ficheiro de perfil. A instância pode chamar-se openvpn@, openvpn-client@, openvpn-server@ ou algo específico da distribuição, e adivinhar o nome leva-o ao modelo errado. A saída de estado indica a unidade que realmente correu, e esse é o único nome que importa aqui. Copie-o exatamente, incluindo qualquer sufixo.
Os comandos seguintes descrevem essa unidade sem alterar nada. systemctl show reporta o caminho do fragmento, o caminho de origem, o estado do ficheiro da unidade, eventuais drop-ins e o que a ativou. list-dependencies --reverse mostra que unidades carregadas apontam para ela. Ambos são só de leitura, por isso execute-os antes de formar uma teoria.
Substitua o nome observado em todo o lado. Um nome de exemplo copiado é a forma mais comum de investigar o serviço errado, e produz respostas confiantes sobre uma unidade que nunca correu.
Leia o modelo para saber o nome do ficheiro
Uma unidade de instância é uma expansão de um modelo, e o modelo decide que ficheiro de configuração lê. Uma linha de comandos que termina num marcador de posição por instância resolve-se no nome da instância mais o sufixo. Se o sufixo for .conf e a instância se chamar old, o ficheiro é old.conf. Se chamar à instância old.conf, o mesmo modelo pede old.conf.conf.
Esse detalhe explica uma classe de duplicados. Alguém acrescenta uma segunda instância com o nome errado, a primeira continua a correr, e o anfitrião acaba com dois túneis e um registo confuso.
Leia o modelo efetivo em vez do ficheiro que recorda ter editado. Um drop-in pode substituir a linha de comandos, e a substituição é o que corre no arranque.
Trace como entra na transação de arranque
Três caminhos são comuns: uma ligação wants a partir de um target, um requisito de outra unidade ou uma unidade gerada por um gerador de pacotes. A listagem de dependências inversas cobre os dois primeiros como entradas carregadas do grafo. Não cobre um temporizador, um hook nem um pedido externo, e por isso a listagem é prova e não uma auditoria completa.
A saída gerada em /run/systemd/generator é um produto, não uma fonte. Editá-la sobrevive apenas até à próxima geração, e por isso uma correção ali aplicada parece bem-sucedida e depois reverte.
Verifique a entrada documentada do pacote antes de assumir de onde o gerador lê. Uma pesquisa não documentada de um diretório é a razão habitual para uma unidade aparecer sem uma ligação de ativação.
Remova a ativação, não apenas o processo
Se a instância estiver diretamente ativada e for realmente obsoleta, systemctl disable --now detém-na e remove a ligação de arranque num só passo. Verifique primeiro que este túnel não é o seu único caminho administrativo para o anfitrião. O comando é um exemplo de ciclo de vida, não uma sugestão de parar todas as VPN da máquina. Execute a verificação antes do comando, não depois.
As duas metades são separáveis e confundem-se com frequência. Desativar não detém um serviço em execução, e parar não remove a ativação, por isso um comando parcial explica um problema que regressa no arranque.
Uma unidade desativada pode ainda ser iniciada por outra unidade ou por um pedido explícito. Quando um gerador é dono da ativação, corrija a entrada do gerador em vez de desativar a sua saída. O mascaramento bloqueia mais caminhos mas pode quebrar dependências, por isso não substitui a compreensão.
Confirme com um reinício, não com um ecrã de estado
Recarregue o systemd se as definições de unidade ou as entradas do gerador mudaram, e depois inspecione o estado resultante. Um recarregamento do daemon não empurra um novo perfil para um túnel em execução, por isso as duas verificações são separadas. Agende um reinício e confirme que a instância continua ausente enquanto o túnel pretendido ainda funciona.
Mantenha o perfil antigo até a sua propriedade ser compreendida, e depois retire-o através do processo pretendido. Sucesso é uma unidade ausente e um caminho de acesso funcional, não uma unidade falhada em falta num ecrã.