O Mac congela após acordar com a VPN: o que registar

Os relatos de um Mac congelado após acordar costumam juntar três falhas numa única queixa. O ponteiro pode continuar a mover-se enquanto o cliente de VPN ignora os cliques, o cliente pode funcionar enquanto uma sessão remota expira, ou todo o ambiente de trabalho pode deixar de aceitar entrada. Cada um destes casos exige provas diferentes, e o primeiro minuto após o bloqueio decide qual está à sua frente. Uma suposição errada envia todos os passos seguintes na direção errada.

O que deixou de responder, e o que apenas deixou de esperar

Comece pelos testes mais baratos: mova o ponteiro e escreva num campo de texto local, abra a vista de estado do próprio cliente e leia o estado que ele comunica, e depois inicie uma operação nova na aplicação privada em vez de retomar a sessão que já estava aberta. Anote as três respostas antes de tocar em mais nada, porque a ordem do que falhou é o primeiro detalhe que as pessoas esquecem.

Cada resultado aponta para um sítio diferente. Uma única sessão encravada coloca a prova do outro lado do túnel, e o Mac é apenas espetador. Um cliente que ignora os cliques enquanto o ambiente de trabalho ainda funciona reduz a procura a esse processo e ao seu registo. Uma máquina que ignora o ponteiro retira a opção de executar o que quer que seja, porque cada comando de inspeção precisa de uma shell que responda.

Mantenha os três casos separados mesmo quando o utilizador os descreve numa só frase. O relatório que apresenta deve dizer que teste falhou primeiro e quais ainda passaram, não que a máquina congelou. É essa distinção que permite ao engenheiro de suporte decidir se olha para a rede, para o cliente ou para o hardware.

Uma cronologia que ainda poderá defender amanhã

O relógio é a parte do registo que não pode ser reconstruída mais tarde. Anote quando a tampa se abriu ou a máquina acordou, quando ocorreu a primeira ação falhada, e se esses dois momentos estavam separados por segundos ou por minutos. Depois escreva se o Mac dormiu de facto ou apenas bloqueou o ecrã, porque são estados diferentes com caminhos de despertar diferentes. O registo de sono é a única parte dessa cronologia que pode verificar depois.

pmset -g log | grep -i -E 'wake|sleep'
log show --last 15m --predicate 'process == "<client-process>"' --style compact

O primeiro comando transforma uma memória vaga num carimbo temporal que pode escrever no segundo. Limite a consulta do registo ao processo do cliente e a uma janela curta, e obtém uma página de saída em vez de um dia inteiro. Copie o identificador do modelo, a compilação do cliente e a rede em que estava para a mesma nota enquanto o ecrã ainda está à sua frente; um relatório montado na manhã seguinte perde a ordem que o tornava legível.

Escolha a captura que corresponde ao sintoma

A Apple documenta três capturas em o guia de diagnóstico do Activity Monitor, e respondem a perguntas diferentes. O Sample Process observa um processo selecionado durante três segundos, o spindump visa uma aplicação que deixou de responder e está prestes a ser forçada a fechar, e o System Diagnostics recolhe registos do sistema num pacote.

Escolha pelo que observou, não pelo hábito. Um cliente que funciona mas se comporta mal recebe um sample, obtido com sample <pid> 3 -file ~/Desktop/sample.txt ou a partir do menu da engrenagem. Uma aplicação que gira sem fim e tem de ser morta recebe o item Spindump desse mesmo menu. Um problema que abrange o cliente e o sistema recebe sudo sysdiagnose -f ~/Desktop. Recolha o sample antes de forçar o fecho quando puder, porque o encerramento destrói exatamente o estado que queria inspecionar, e dê ao ficheiro o nome do evento e da hora em vez do nome da sua suposição sobre a causa.

Trate cada pacote como sensível. Estes relatórios contêm nomes de contas, nomes de anfitriões, caminhos e detalhes de rede, por isso envie-os pelo canal de suporte que a sua organização utiliza em vez de os anexar a um tópico público. Se um relatório tiver de ser reduzido, reduza uma cópia e deixe o original intacto.

Quando o próprio ponteiro não se mexe

Uma interface morta altera a ordem das operações. Não pode recolher o sample de um processo nem executar uma consulta a partir de uma shell que não responde, por isso o primeiro objetivo é a recuperação e o segundo é um registo. Um reinício forçado é por vezes a única saída, e é também o momento em que os detalhes mais úteis desaparecem. Anote a hora, as janelas que estavam abertas e se o menu de rede mostrava ligação antes de reiniciar; essas observações sobrevivem ao reinício, ainda que o estado do processo não sobreviva.

Quando a máquina volta, resista à conclusão de que o reinício encontrou o culpado. Restaurou o serviço e não nomeou nada. Só uma repetição com uma alteração controlada pode apontar para um componente.

Se o bloqueio voltar, altere uma condição por tentativa: a rede, a versão do cliente ou o modo de suspensão. Guarde primeiro o trabalho remoto, e evite repetir suspensões forçadas numa máquina de produção, porque os ciclos duros repetidos arriscam perda de dados e produzem muitas vezes uma falha diferente da que está a perseguir. Anote cada tentativa com as suas condições para que a seguinte seja comparável e não anedótica.

Entregue um evento, não um humor

A entrega que consegue ação nomeia quatro coisas: o que deixou de responder, quando aconteceu, como estava a rede naquele momento, e que captura cobre a janela. Acrescente a versão do cliente e a compilação do macOS, e depois pare. Tanto a equipa de plataforma como o fornecedor do cliente podem agir sobre essa frase, e nenhum dos dois pode agir sobre uma descrição de frustração. Mantenha o registo num só lugar e acrescente-lhe entradas em vez de recontar a história de cada vez; se uma atualização mudou o comportamento, indique qual, porque isso também é prova.

Um bom registo também diz o que já descartou. Se uma aplicação local respondeu durante o bloqueio, diga-o; se o registo de sono mostra um despertar real e não um bloqueio, diga isso também. A pessoa seguinte não devia ter de repetir testes que já fez.

Antes de fechar o ticket, verifique três coisas: o carimbo temporal vem do registo de sono e não da memória, a captura corresponde ao sintoma que viu de facto, e o pacote está no local aprovado. Se faltar qualquer uma das três, o relatório não está pronto a enviar.