Il Mac si blocca dopo il risveglio con la VPN: cosa registrare

I rapporti su un Mac bloccato dopo il risveglio spesso fondono tre guasti in un’unica lamentela. Il puntatore può ancora muoversi mentre il client VPN ignora i clic, il client può funzionare mentre una singola sessione remota scade, oppure l’intera scrivania può smettere di accettare input. Ciascuno di questi casi richiede prove diverse, e il primo minuto dopo il blocco decide quale state guardando. Un’ipotesi sbagliata manda ogni passo successivo nella direzione sbagliata.

Cosa ha smesso di rispondere e cosa ha solo smesso di aspettare

Cominciate dai test più economici: muovete il puntatore e digitate in un campo di testo locale, aprite la vista di stato del client e leggete lo stato che riporta, poi avviate una nuova operazione nell’applicazione privata invece di riprendere la sessione già aperta. Annotate le tre risposte prima di toccare qualsiasi altra cosa, perché l’ordine di ciò che ha fallito è il primo dettaglio che le persone dimenticano.

Ogni esito punta altrove. Una sola sessione bloccata mette la prova dall’altra parte del tunnel, e il Mac è solo spettatore. Un client che ignora i clic mentre la scrivania funziona ancora restringe la ricerca a quel processo e al suo log. Una macchina che ignora il puntatore elimina la possibilità di eseguire qualcosa, perché ogni comando di ispezione richiede una shell che risponda.

Tenete separati i tre casi anche quando l’utente li descrive in una sola frase. Il rapporto che presentate deve dire quale test ha fallito per primo e quali ancora passavano, non che la macchina si è bloccata. È questa distinzione che permette a un ingegnere del supporto di decidere se guardare la rete, il client o l’hardware.

Una cronologia che potrete ancora difendere domani

L’orologio è la parte del registro che non si può ricostruire dopo. Annotate quando si è aperto il coperchio o si è svegliata la macchina, quando è avvenuta la prima azione fallita, e se quei due momenti erano separati da secondi o da minuti. Poi scrivete se il Mac ha dormito davvero o ha solo bloccato lo schermo, perché sono stati diversi con percorsi di risveglio diversi. Il log del sonno è l’unica parte di quella cronologia che potete controllare dopo.

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

Il primo comando trasforma un ricordo vago in un timestamp che potete digitare nel secondo. Limitate la query del log al processo del client e a una finestra breve, e ottenete una pagina di output invece di un’intera giornata. Copiate l’identificatore del modello, la build del client e la rete su cui eravate nella stessa nota mentre lo schermo è ancora davanti a voi; un rapporto messo insieme il mattino dopo perde l’ordine che lo rendeva leggibile.

Scegliete la cattura che corrisponde al sintomo

Apple documenta tre catture in la guida diagnostica di Activity Monitor, e rispondono a domande diverse. Sample Process osserva un processo selezionato per tre secondi, spindump prende di mira un’applicazione che ha smesso di rispondere e sta per essere chiusa a forza, e System Diagnostics raccoglie i log di sistema in un pacchetto.

Scegliete in base a ciò che avete osservato, non per abitudine. Un client che gira ma si comporta male riceve un sample, preso con sample <pid> 3 -file ~/Desktop/sample.txt o dal menu dell’ingranaggio. Un’applicazione che gira all’infinito e va uccisa riceve la voce Spindump da quello stesso menu. Un problema che coinvolge client e sistema riceve sudo sysdiagnose -f ~/Desktop. Prendete il sample prima di forzare la chiusura quando potete, perché la terminazione distrugge esattamente lo stato che volevate ispezionare, e nominate il file dopo l’evento e l’ora invece che dopo la vostra ipotesi sulla causa.

Trattate ogni pacchetto come sensibile. Questi rapporti contengono nomi di account, nomi host, percorsi e dettagli di rete, quindi inviateli attraverso il canale di supporto che usa la vostra organizzazione invece di allegarli a un thread pubblico. Se un rapporto deve essere ridotto, riducete una copia e lasciate intatto l’originale.

Quando il puntatore stesso non si muove

Un’interfaccia morta cambia l’ordine delle operazioni. Non potete campionare un processo né eseguire una query da una shell che non risponde, quindi il primo obiettivo è il recupero e il secondo è un registro. Un riavvio forzato è a volte l’unica via d’uscita, ed è anche il momento in cui i dettagli più utili spariscono. Annotate l’ora, le finestre aperte e se il menu di rete mostrava una connessione prima di riavviare; quelle osservazioni sopravvivono al riavvio anche se lo stato del processo no.

Quando la macchina è tornata, resistete alla conclusione che il riavvio abbia trovato il colpevole. Ha ripristinato il servizio e non ha nominato nulla. Solo una ripetizione con un cambiamento controllato può indicare un componente.

Se il blocco torna, cambiate una condizione per tentativo: la rete, la versione del client o la modalità di sospensione. Salvate prima il lavoro remoto, ed evitate di ripetere sospensioni forzate su una macchina di produzione, perché i cicli duri ripetuti rischiano perdita di dati e spesso producono un guasto diverso da quello che state inseguendo. Annotate ogni tentativo con le sue condizioni perché il successivo sia confrontabile e non aneddotico.

Consegnate un evento, non un umore

La consegna che ottiene un’azione nomina quattro cose: cosa ha smesso di rispondere, quando è successo, com’era la rete in quel momento, e quale cattura copre la finestra. Aggiungete la versione del client e la build di macOS, poi fermatevi. Sia il team della piattaforma sia il fornitore del client possono agire su quella frase, e nessuno dei due può agire su una descrizione di frustrazione. Tenete il registro in un solo posto e aggiungete elementi invece di raccontare di nuovo la storia ogni volta; se un aggiornamento ha cambiato il comportamento, indicate quale, perché anche quello è una prova.

Un buon registro dice anche cosa avete già escluso. Se un’applicazione locale rispondeva durante il blocco, ditelo; se il log del sonno mostra un risveglio reale e non un blocco, ditelo pure. La persona successiva non dovrebbe dover ripetere test che avete già fatto.

Prima di chiudere il ticket, controllate tre cose: il timestamp viene dal log del sonno e non dalla memoria, la cattura corrisponde al sintomo che avete visto davvero, e il pacchetto si trova nella posizione approvata. Se manca uno dei tre, il rapporto non è pronto per essere inviato.