VPN과 함께 잠에서 깬 뒤 Mac이 멈춘다: 무엇을 기록할까

잠에서 깬 뒤 Mac이 멈췄다는 보고는 흔히 세 가지 실패를 하나의 불평으로 합칩니다. VPN 클라이언트가 클릭을 무시하는 동안 포인터는 아직 움직일 수 있고, 원격 세션 하나가 만료되는 동안 클라이언트는 동작할 수 있으며, 데스크톱 전체가 입력을 받지 않을 수도 있습니다. 각각은 다른 증거를 요구하며, 멈춘 뒤 첫 일 분이 여러분이 어느 쪽을 보고 있는지 결정합니다. 잘못된 추측은 이후의 모든 단계를 잘못된 방향으로 보냅니다.

응답을 멈춘 것과 기다리기만 멈춘 것

가장 값싼 테스트부터 시작하세요, 즉 포인터를 움직여 로컬 텍스트 필드에 입력하고, 클라이언트 자체의 상태 보기를 열어 보고되는 상태를 읽은 다음, 이미 열려 있던 세션을 재개하는 대신 비공개 앱에서 새 작업을 시작합니다. 다른 무엇을 건드리기 전에 세 가지 답을 적으세요, 무엇이 실패했는지의 순서는 사람들이 가장 먼저 잊는 세부 사항이기 때문입니다.

각 결과는 다른 곳을 가리킵니다. 세션 하나가 막혀 있으면 증거는 터널 건너편에 있고, Mac은 방관자일 뿐입니다. 데스크톱이 아직 동작하는데 클릭을 무시하는 클라이언트라면 조사 범위는 그 프로세스와 로그로 좁혀집니다. 포인터를 무시하는 기기에서는 무엇이든 실행할 선택지 자체가 사라집니다, 모든 점검 명령에는 응답하는 셸이 필요하기 때문입니다.

사용자가 한 문장으로 설명하더라도 세 경우를 분리해 두세요. 제출하는 보고서에는 어느 테스트가 먼저 실패했고 어느 것이 아직 통과했는지를 써야 하며, 기기가 멈췄다고 쓰면 안 됩니다. 이 구분이 있어야 지원 엔지니어가 네트워크, 클라이언트, 하드웨어 중 무엇을 볼지 결정할 수 있습니다.

내일도 변호할 수 있는 타임라인

시계는 나중에 다시 구성할 수 없는 기록의 일부입니다. 덮개가 열린 시각이나 기기가 깨어난 시각, 첫 실패 동작이 일어난 시각, 그리고 그 두 순간이 몇 초인지 몇 분인지 적어 두세요. 다음으로 Mac이 정말 잠들었는지 화면만 잠갔는지 적으세요, 서로 다른 상태이고 깨어나는 경로도 다르기 때문입니다. 잠자기 로그는 그 타임라인에서 나중에 확인할 수 있는 유일한 부분입니다.

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

첫 명령은 흐릿한 기억을 두 번째 명령에 입력할 수 있는 타임스탬프로 바꿉니다. 로그 조회를 클라이언트 프로세스와 짧은 구간으로 제한하면 하루치가 아니라 한 페이지 출력을 얻습니다. 화면이 아직 눈앞에 있을 때 모델 식별자, 클라이언트 빌드, 접속한 네트워크를 같은 메모에 복사하세요, 다음 날 아침에 조립한 보고서는 읽기 쉽게 만든 순서를 잃기 때문입니다.

증상에 맞는 캡처를 고르세요

Apple은 Activity Monitor 진단 안내서에서 세 가지 캡처를 설명하며, 각각 다른 질문에 답합니다. Sample Process는 선택한 프로세스 하나를 삼 초 동안 관찰하고, spindump는 응답을 멈추고 곧 강제 종료될 앱을 대상으로 하며, System Diagnostics는 시스템 로그를 번들로 모읍니다.

습관이 아니라 관찰한 내용으로 고르세요. 동작하지만 잘못 행동하는 클라이언트에는 sample <pid> 3 -file ~/Desktop/sample.txt 또는 톱니바퀴 메뉴에서 가져온 sample을 남깁니다. 끝없이 돌아가 죽여야 하는 앱에는 같은 메뉴의 Spindump 항목을 사용합니다. 클라이언트와 시스템에 걸친 문제에는 sudo sysdiagnose -f ~/Desktop를 사용합니다. 가능하면 강제 종료 전에 sample을 남기세요, 종료는 보려던 상태를 정확히 파괴하므로 파일 이름은 원인에 대한 추측이 아니라 사건과 시각으로 붙입니다.

모든 번들을 민감한 것으로 다루세요. 이 보고서에는 계정 이름, 호스트 이름, 경로, 네트워크 세부 정보가 들어 있으므로 공개 스레드에 첨부하지 말고 조직이 쓰는 지원 경로로 보내세요. 보고서를 줄여야 한다면 사본을 줄이고 원본은 그대로 두세요.

포인터 자체가 움직이지 않을 때

죽은 인터페이스는 작업 순서를 바꿉니다. 응답하지 않는 셸에서는 프로세스를 샘플링할 수도, 조회를 실행할 수도 없으므로 첫 목표는 복구이고 두 번째는 기록입니다. 강제 재시동이 유일한 출구일 때가 있고, 그것은 가장 유용한 세부 정보가 사라지는 순간이기도 합니다. 재시동 전에 시각, 열려 있던 창, 네트워크 메뉴에 연결이 표시되었는지를 적으세요; 프로세스 상태는 남지 않아도 그 관찰은 재시동을 넘어 남습니다.

기기가 돌아오면 재시동이 범인을 찾았다는 결론에 저항하세요. 재시동은 서비스를 되돌렸을 뿐 아무것도 지목하지 않았습니다. 통제된 변경 하나를 둔 반복만이 구성 요소를 가리킬 수 있습니다.

멈춤이 다시 나타나면 시도마다 조건 하나만 바꾸세요, 네트워크, 클라이언트 버전, 잠자기 모드 중 하나입니다. 먼저 원격 작업을 저장하고, 생산 기기에서 강제 잠자기를 반복하지 마세요, 반복되는 강한 주기는 데이터 손실 위험이 있고 추적 중인 실패와 다른 실패를 자주 만들기 때문입니다. 각 시도를 조건과 함께 적어 다음 시도가 일화가 아니라 비교 가능하게 하세요.

기분이 아니라 사건 하나를 인계하세요

행동을 이끌어내는 인계는 네 가지를 지목합니다, 무엇이 응답을 멈췄는지, 언제 일어났는지, 그 순간 네트워크가 어떠했는지, 어느 캡처가 그 구간을 덮는지입니다. 클라이언트 버전과 macOS 빌드를 더하고 나서 멈추세요. 플랫폼 팀과 클라이언트 공급자 모두 그 문장으로 움직일 수 있지만, 좌절에 대한 설명으로는 어느 쪽도 움직일 수 없습니다. 기록을 한곳에 두고 매번 이야기를 다시 하는 대신 덧붙이세요, 업데이트가 동작을 바꿨다면 어느 것인지 적으세요, 그것도 증거이기 때문입니다.

좋은 기록은 이미 배제한 것도 말합니다. 멈춤 동안 로컬 앱이 응답했다면 그렇게 적고, 잠자기 로그가 잠금이 아니라 실제 깨어남을 보여 준다면 그것도 적으세요. 다음 사람이 이미 한 테스트를 다시 하지 않아도 되어야 합니다.

티켓을 닫기 전에 확인할 것은 세 가지입니다, 타임스탬프가 기억이 아니라 잠자기 로그에서 오는지, 캡처가 실제로 본 증상과 맞는지, 번들이 승인된 위치에 있는지입니다. 셋 중 하나라도 빠지면 보고서는 보낼 준비가 되지 않은 것입니다.