De Mac loopt vast na het ontwaken met de VPN: wat je moet vastleggen

Meldingen over een bevroren Mac na het ontwaken voegen vaak drie fouten samen in één klacht. De aanwijzer kan nog bewegen terwijl de VPN-client klikken negeert, de client kan werken terwijl één externe sessie verloopt, of het hele bureaublad kan stoppen met invoer aannemen. Elk daarvan vraagt ander bewijs, en de eerste minuut na de bevriezing bepaalt welke je voor je hebt. Een verkeerde gok stuurt elke volgende stap de verkeerde kant op.

Wat stopte met antwoorden, en wat stopte alleen met wachten

Begin met de goedkoopste tests: beweeg de aanwijzer en typ in een lokaal tekstveld, open de eigen statusweergave van de client en lees de toestand die hij meldt, en start daarna een nieuwe bewerking in de privé-app in plaats van de al open sessie te hervatten. Schrijf de drie antwoorden op voordat je iets anders aanraakt, want de volgorde van wat faalde is het eerste detail dat mensen vergeten.

Elke uitkomst wijst ergens anders heen. Eén vastgelopen sessie zet het bewijs aan de andere kant van de tunnel, en de Mac is alleen toeschouwer. Een client die klikken negeert terwijl het bureaublad nog werkt, vernauwt de zoektocht tot dat proces en zijn log. Een machine die de aanwijzer negeert, haalt de mogelijkheid weg om iets te draaien, want elke inspectieopdracht heeft een shell nodig die antwoordt.

Houd de drie gevallen gescheiden, ook wanneer de gebruiker ze in één zin beschrijft. Het rapport dat je indient, moet zeggen welke test eerst faalde en welke nog slaagden, niet dat de machine bevroor. Dat onderscheid is wat een supportingenieur laat beslissen of hij naar het netwerk, de client of de hardware kijkt.

Een tijdlijn die je morgen nog kunt verdedigen

De klok is het deel van het verslag dat later niet opnieuw kan worden opgebouwd. Noteer wanneer het deksel openging of de machine wakker werd, wanneer de eerste mislukte actie gebeurde, en of die twee momenten seconden of minuten uit elkaar lagen. Schrijf daarna op of de Mac echt sliep of alleen het scherm vergrendelde, want dat zijn verschillende toestanden met verschillende ontwaakpaden. Het slaplog is het enige deel van die tijdlijn dat je achteraf kunt controleren.

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

De eerste opdracht verandert een vaag geheugen in een tijdstempel die je in de tweede kunt typen. Beperk de logquery tot het clientproces en een kort venster, en je krijgt één pagina uitvoer in plaats van een hele dag. Kopieer de modelidentificatie, de clientbuild en het netwerk waarop je zat in dezelfde notitie terwijl het scherm nog voor je staat; een rapport dat de volgende ochtend wordt samengesteld, verliest de volgorde die het leesbaar maakte.

Kies de opname die bij het symptoom past

Apple documenteert drie opnamen in de diagnosesgids van Activity Monitor, en ze beantwoorden verschillende vragen. Sample Process volgt drie seconden één geselecteerd proces, spindump richt zich op een app die niet meer reageert en op het punt staat geforceerd te sluiten, en System Diagnostics verzamelt systeemlogs in een bundel.

Kies op basis van wat je hebt waargenomen, niet uit gewoonte. Een client die draait maar zich slecht gedraagt, krijgt een sample, genomen met sample <pid> 3 -file ~/Desktop/sample.txt of uit het tandwielmenu. Een app die eindeloos draait en moet worden gedood, krijgt het Spindump-item uit datzelfde menu. Een probleem dat de client en het systeem omvat, krijgt sudo sysdiagnose -f ~/Desktop. Neem de sample voordat je geforceerd sluit als je kunt, want beëindiging vernietigt precies de toestand die je wilde inspecteren, en noem het bestand naar de gebeurtenis en de tijd in plaats van naar je gok over de oorzaak.

Behandel elke bundel als gevoelig. Deze rapporten bevatten accountnamen, hostnamen, paden en netwerkdetails, dus stuur ze via het supportkanaal dat je organisatie gebruikt in plaats van ze aan een openbare thread te hangen. Als een rapport moet worden ingekort, kort dan een kopie in en laat het origineel intact.

Wanneer de aanwijzer zelf niet beweegt

Een dood interface verandert de volgorde van de handelingen. Je kunt geen sample van een proces nemen en geen query uitvoeren vanuit een shell die niet antwoordt, dus het eerste doel is herstel en het tweede is een verslag. Een geforceerde herstart is soms de enige uitweg, en het is ook het moment waarop de nuttigste details verdwijnen. Noteer de tijd, de vensters die open stonden en of het netwerkmenu een verbinding toonde voordat je herstart; die waarnemingen overleven de herstart ook al doet de procestoestand dat niet.

Als de machine terug is, weersta de conclusie dat de herstart de schuldige heeft gevonden. Het herstelde de dienst en noemde niets. Alleen een herhaling met één gecontroleerde wijziging kan naar een component wijzen.

Als de bevriezing terugkomt, wijzig één voorwaarde per poging: het netwerk, de clientversie of de slaapmodus. Sla eerst extern werk op, en vermijd herhaalde geforceerde slaapstanden op een productiemachine, want herhaalde harde cycli riskeren gegevensverlies en leveren vaak een andere fout op dan degene die je achtervolgt. Schrijf elke poging op met de voorwaarden, zodat de volgende vergelijkbaar is en niet anekdotisch.

Draag één gebeurtenis over, geen stemming

De overdracht die actie oplevert, noemt vier dingen: wat stopte met antwoorden, wanneer het gebeurde, hoe het netwerk er op dat moment uitzag, en welke opname dat venster dekt. Voeg de clientversie en de macOS-build toe, en stop dan. Zowel het platformteam als de clientleverancier kan op die zin handelen, en geen van beide kan handelen op een beschrijving van frustratie. Houd het verslag op één plek en vul het aan in plaats van het verhaal elke keer opnieuw te vertellen; als een update het gedrag veranderde, noteer welke, want dat is ook bewijs.

Een goed verslag zegt ook wat je al hebt uitgesloten. Als een lokale app antwoordde tijdens de bevriezing, zeg dat; als het slaplog een echte ontwaking en geen vergrendeling toont, zeg dat ook. De volgende persoon zou tests die je al hebt gedaan niet opnieuw moeten doen.

Voordat je het ticket sluit, controleer drie dingen: de tijdstempel komt uit het slaplog en niet uit het geheugen, de opname past bij het symptoom dat je echt zag, en de bundel staat op de goedgekeurde plek. Als een van de drie ontbreekt, is het rapport niet klaar om te versturen.