Identifique o auxiliar de VPN do Mac antes de encerrar o processo

Trate uma mensagem sobre um auxiliar que já está em execução como uma pista de ciclo de vida, não como permissão para começar a matar processos. O passo perigoso não é a paragem em si, mas a identificação que a antecede, porque podem existir vários componentes com nomes semelhantes num único Mac e só um deles é dono da ligação. Construa primeiro o registo de identidade. Depois decida se parar é sequer a ação correta.

Construa um registo de identidade antes de agir

Quatro factos tornam um processo identificável: o PID atual com a hora de início, o executável e o produto a que pertence, o utilizador ou contexto de privilégios em que corre, e aquilo que o iniciou. ps -o pid,ppid,user,etime,command -p 1234 dá-lhe os primeiros três numa só linha, incluindo há quanto tempo o processo está vivo. O Monitor de Atividade mostra a mesma informação de forma mais amigável. Acrescente o controlador, ou seja, a aplicação ou serviço responsável por o iniciar e parar. Com esses quatro, um processo deixa de ser um nome e passa a ser um objeto sobre o qual se pode raciocinar.

Se um dos quatro for desconhecido, pare aí. Um componente desconhecido é uma pergunta para o editor ou o administrador, não uma experiência.

O PID num registo antigo pertence agora a outra pessoa

Os IDs de processo são reciclados, e um número copiado do registo de ontem pode agora apontar para algo completamente alheio. Compare a hora de início com o carimbo temporal do registo antes de tirar qualquer conclusão. O mesmo se aplica a um nome curto: duas compilações de um produto podem incluir auxiliares com nomes idênticos e propósitos diferentes. A identidade é o tuplo, nunca o número sozinho.

Separe os papéis antes de tocar em mais alguma coisa. O cliente de uma única ligação, um auxiliar partilhado que serve várias aplicações e um servidor que aceita sessões de outras pessoas parecem todos um processo em segundo plano numa lista. Só um deles pode ser parado sem consequências que não tenha considerado.

Pare através do proprietário, não através do sinal

Comece pelo controlo que é dono da coisa: o botão Desligar da ligação, o comando de paragem suportado pelo serviço, ou a ação do próprio agente de gestão. Esses caminhos executam a desmontagem que o produto espera, que inclui remover rotas e fechar o dispositivo de túnel. Um sinal salta tudo isso e deixa estado para trás.

Observe o que resta depois. Um processo que fica residente pode estar à espera da ligação seguinte, o que é uma escolha de conceção e não uma paragem falhada.

Porque é que um supervisor reinicia o que matou

Se um daemon de arranque ou uma política de ligação automática quer o túnel ativo, matar o processo não exprime nada. O supervisor vê a saída e volta a iniciá-lo, por vezes antes de terminar a leitura do registo.

Encontre o supervisor antes de lutar contra ele. launchctl list mostra as tarefas carregadas e as respetivas etiquetas, e uma tarefa com definição keep-alive reinicia ao sair, por conceção. A ação correta aí é mudar a intenção: descarregar a tarefa, desativar a política de ligação automática, ou pedir ao administrador que o faça. Forçar a saída é uma ferramenta diferente com um significado diferente, e pertence a um procedimento de recuperação documentado para um processo bloqueado, não à gestão corrente de ligações.

Registe o evento de ciclo de vida, não o kill

Anote a identidade do componente, a versão do cliente, o primeiro evento relevante de ciclo de vida e o que fez. O evento importa mais do que a ação, porque duas instâncias a aparecer no início de sessão são um problema de ordenação de arranque que vai repetir-se. Um registo que nomeia o executável e o seu controlador permite que a próxima pessoa o reproduza.

Depois verifique o estado pretendido: o serviço de que o utilizador precisava e o recurso privado que ele alcança. Evite o pipeline que procura uma subcadeia e força o encerramento de todas as correspondências, porque descarta tudo o que ficou atrás e normalmente destrói a prova de porque existiam duas instâncias. Se o processo continua a voltar, a conclusão é um defeito de configuração ou de ordenação, e a correção pertence a quem é dono do comportamento de arranque do cliente.