Le Mac se fige après le réveil avec le VPN : ce qu’il faut consigner

Les rapports sur un Mac figé après le réveil fusionnent souvent trois défaillances en une seule plainte. Le pointeur peut encore bouger tandis que le client VPN ignore les clics, le client peut fonctionner tandis qu’une session distante expire, ou tout le bureau peut cesser d’accepter les entrées. Chacun de ces cas demande des preuves différentes, et la première minute après le gel décide lequel vous avez devant vous. Une mauvaise supposition envoie chaque étape suivante dans la mauvaise direction.

Ce qui a cessé de répondre, et ce qui a seulement cessé d’attendre

Commencez par les tests les moins coûteux : déplacez le pointeur et tapez dans un champ de texte local, ouvrez la vue d’état du client et lisez l’état qu’il rapporte, puis lancez une nouvelle opération dans l’application privée au lieu de reprendre la session déjà ouverte. Notez les trois réponses avant de toucher à autre chose, car l’ordre de ce qui a échoué est le premier détail que les gens oublient.

Chaque résultat pointe ailleurs. Une seule session bloquée place la preuve de l’autre côté du tunnel, et le Mac n’est que spectateur. Un client qui ignore les clics alors que le bureau fonctionne encore réduit la recherche à ce processus et à son journal. Une machine qui ignore le pointeur supprime la possibilité d’exécuter quoi que ce soit, car chaque commande d’inspection a besoin d’un shell qui répond.

Gardez les trois cas séparés même lorsque l’utilisateur les décrit en une seule phrase. Le rapport que vous déposez doit dire quel test a échoué en premier et lesquels passaient encore, pas que la machine s’est figée. Cette distinction permet à un ingénieur du support de décider s’il doit regarder le réseau, le client ou le matériel.

Une chronologie que vous pourrez encore défendre demain

L’horloge est la partie du dossier qui ne peut pas être reconstruite plus tard. Notez quand le capot s’est ouvert ou quand la machine s’est réveillée, quand la première action ratée a eu lieu, et si ces deux moments étaient séparés par des secondes ou des minutes. Écrivez ensuite si le Mac a vraiment dormi ou s’il a seulement verrouillé son écran, car ce sont des états différents avec des chemins de réveil différents. Le journal de sommeil est la seule partie de cette chronologie que vous pouvez vérifier ensuite.

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

La première commande transforme un souvenir vague en horodatage que vous pouvez saisir dans la seconde. Limitez la requête du journal au processus du client et à une courte fenêtre, et vous obtenez une page de sortie au lieu d’une journée entière. Copiez l’identifiant du modèle, la version du client et le réseau sur lequel vous étiez dans la même note pendant que l’écran est encore devant vous ; un rapport assemblé le lendemain matin perd l’ordre qui le rendait lisible.

Choisissez la capture qui correspond au symptôme

Apple documente trois captures dans le guide de diagnostic d’Activity Monitor, et elles répondent à des questions différentes. Sample Process observe un processus sélectionné pendant trois secondes, spindump cible une application qui a cessé de répondre et qui va être forcée à quitter, et System Diagnostics rassemble les journaux système dans un paquet.

Choisissez d’après ce que vous avez observé, pas d’après l’habitude. Un client qui tourne mais se comporte mal reçoit un sample, pris avec sample <pid> 3 -file ~/Desktop/sample.txt ou depuis le menu de l’engrenage. Une application qui tourne sans fin et doit être tuée reçoit l’élément Spindump de ce même menu. Un problème qui couvre le client et le système reçoit sudo sysdiagnose -f ~/Desktop. Prenez le sample avant de forcer à quitter quand vous pouvez, car la terminaison détruit exactement l’état que vous vouliez inspecter, et nommez le fichier d’après l’événement et l’heure plutôt que d’après votre supposition sur la cause.

Traitez chaque paquet comme sensible. Ces rapports contiennent des noms de compte, des noms d’hôte, des chemins et des détails réseau, donc envoyez-les par le canal de support utilisé par votre organisation au lieu de les joindre à un fil public. Si un rapport doit être réduit, réduisez une copie et laissez l’original intact.

Quand le pointeur lui-même ne bouge pas

Une interface morte change l’ordre des opérations. Vous ne pouvez ni échantillonner un processus ni exécuter une requête depuis un shell qui ne répond pas, donc le premier objectif est la reprise et le second est un dossier. Un redémarrage forcé est parfois la seule issue, et c’est aussi le moment où les détails les plus utiles disparaissent. Notez l’heure, les fenêtres qui étaient ouvertes et si le menu réseau affichait une connexion avant de redémarrer ; ces observations survivent au redémarrage même si l’état du processus n’y survit pas.

Une fois la machine revenue, résistez à la conclusion que le redémarrage a trouvé le coupable. Il a rétabli le service et n’a rien nommé. Seule une répétition avec un changement contrôlé peut pointer vers un composant.

Si le gel revient, changez une condition par tentative : le réseau, la version du client ou le mode de veille. Enregistrez d’abord le travail distant, et évitez de répéter des veilles forcées sur une machine de production, car des cycles durs répétés risquent une perte de données et produisent souvent une défaillance différente de celle que vous poursuivez. Notez chaque tentative avec ses conditions pour que la suivante soit comparable et non anecdotique.

Transmettez un événement, pas une humeur

La transmission qui obtient une action nomme quatre choses : ce qui a cessé de répondre, quand cela s’est produit, à quoi ressemblait le réseau à ce moment-là, et quelle capture couvre la fenêtre. Ajoutez la version du client et la version de macOS, puis arrêtez-vous. L’équipe plateforme comme le fournisseur du client peuvent agir sur cette phrase, et aucun des deux ne peut agir sur une description de frustration. Gardez le dossier au même endroit et complétez-le au lieu de raconter à nouveau l’histoire chaque fois ; si une mise à jour a changé le comportement, précisez laquelle, car c’est aussi une preuve.

Un bon dossier indique aussi ce que vous avez déjà écarté. Si une application locale répondait pendant le gel, dites-le ; si le journal de sommeil montre un vrai réveil et non un verrouillage, dites-le aussi. La personne suivante ne devrait pas avoir à refaire des tests que vous avez déjà faits.

Avant de clôturer le ticket, vérifiez trois choses : l’horodatage vient du journal de sommeil et non de la mémoire, la capture correspond au symptôme que vous avez réellement vu, et le paquet se trouve à l’emplacement approuvé. Si l’un des trois manque, le rapport n’est pas prêt à être envoyé.