Mac bị treo sau khi thức dậy với VPN: cần ghi lại những gì

Các báo cáo về Mac bị treo sau khi thức dậy thường gộp ba lỗi vào một khiếu nại. Con trỏ có thể vẫn di chuyển trong khi ứng dụng khách VPN bỏ qua cú nhấp, ứng dụng khách có thể hoạt động trong khi một phiên từ xa hết hạn, hoặc toàn bộ màn hình có thể ngừng nhận dữ liệu vào. Mỗi trường hợp cần bằng chứng khác nhau, và phút đầu tiên sau khi treo quyết định bạn đang nhìn trường hợp nào. Một phỏng đoán sai sẽ đưa mọi bước sau đi sai hướng.

Cái gì ngừng phản hồi, và cái gì chỉ ngừng chờ

Hãy bắt đầu bằng các phép thử rẻ nhất: di chuyển con trỏ và gõ vào một trường văn bản cục bộ, mở chế độ xem trạng thái của chính ứng dụng khách và đọc trạng thái mà nó báo, sau đó bắt đầu một thao tác mới trong ứng dụng riêng thay vì tiếp tục phiên đã mở. Ghi lại ba câu trả lời trước khi chạm vào bất cứ thứ gì khác, vì thứ tự của những gì đã hỏng là chi tiết đầu tiên mà người ta quên.

Mỗi kết quả chỉ về một nơi khác. Một phiên bị kẹt đặt bằng chứng ở phía bên kia đường hầm, và Mac chỉ là người quan sát. Ứng dụng khách bỏ qua cú nhấp trong khi màn hình vẫn hoạt động sẽ thu hẹp việc tìm kiếm vào tiến trình đó và nhật ký của nó. Máy bỏ qua con trỏ sẽ loại bỏ khả năng chạy bất cứ thứ gì, vì mọi lệnh kiểm tra đều cần một lớp vỏ phản hồi.

Giữ ba trường hợp tách biệt ngay cả khi người dùng mô tả chúng trong một câu. Báo cáo bạn gửi phải nói phép thử nào hỏng trước và phép thử nào vẫn qua, không phải rằng máy đã treo. Chính sự phân biệt đó giúp kỹ sư hỗ trợ quyết định nhìn vào mạng, ứng dụng khách hay phần cứng.

Một dòng thời gian mà ngày mai bạn vẫn bảo vệ được

Đồng hồ là phần của hồ sơ không thể dựng lại sau đó. Ghi lại khi nắp mở hoặc khi máy thức dậy, khi hành động hỏng đầu tiên xảy ra, và liệu hai thời điểm đó cách nhau vài giây hay vài phút. Sau đó viết xem Mac thực sự ngủ hay chỉ khóa màn hình, vì đó là những trạng thái khác nhau với đường thức dậy khác nhau. Nhật ký ngủ là phần duy nhất của dòng thời gian đó mà bạn có thể kiểm tra về sau.

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

Lệnh đầu tiên biến một ký ức mơ hồ thành dấu thời gian mà bạn có thể gõ vào lệnh thứ hai. Giới hạn truy vấn nhật ký vào tiến trình của ứng dụng khách và một khoảng ngắn, và bạn nhận được một trang kết quả thay vì cả ngày. Sao chép mã định danh kiểu máy, bản dựng ứng dụng khách và mạng bạn đang dùng vào cùng một ghi chú khi màn hình còn trước mặt; báo cáo lắp ghép sáng hôm sau sẽ mất thứ tự khiến nó dễ đọc.

Chọn cách ghi phù hợp với triệu chứng

Apple ghi lại ba cách thu thập trong hướng dẫn chẩn đoán của Activity Monitor, và chúng trả lời những câu hỏi khác nhau. Sample Process theo dõi một tiến trình được chọn trong ba giây, spindump nhắm vào ứng dụng đã ngừng phản hồi và sắp bị buộc đóng, còn System Diagnostics thu thập nhật ký hệ thống vào một gói.

Chọn theo điều bạn quan sát, không theo thói quen. Ứng dụng khách chạy nhưng cư xử sai sẽ nhận một sample, lấy bằng sample <pid> 3 -file ~/Desktop/sample.txt hoặc từ menu bánh răng. Ứng dụng quay mãi và phải bị giết sẽ nhận mục Spindump từ chính menu đó. Vấn đề bao trùm cả ứng dụng khách và hệ thống sẽ nhận sudo sysdiagnose -f ~/Desktop. Hãy lấy sample trước khi buộc đóng khi có thể, vì việc kết thúc phá hủy đúng trạng thái bạn muốn kiểm tra, và đặt tên tệp theo sự kiện và thời điểm thay vì theo phỏng đoán của bạn về nguyên nhân.

Xử lý mọi gói dữ liệu như thông tin nhạy cảm. Các báo cáo này chứa tên tài khoản, tên máy chủ, đường dẫn và chi tiết mạng, nên hãy gửi chúng qua kênh hỗ trợ mà tổ chức của bạn dùng thay vì đính kèm vào một chủ đề công khai. Nếu phải cắt bớt báo cáo, hãy cắt một bản sao và giữ nguyên bản gốc.

Khi bản thân con trỏ không di chuyển

Giao diện chết làm thay đổi thứ tự thao tác. Bạn không thể lấy sample của tiến trình hay chạy truy vấn từ một lớp vỏ không phản hồi, nên mục tiêu đầu tiên là khôi phục và mục tiêu thứ hai là ghi chép. Khởi động lại cưỡng bức đôi khi là lối thoát duy nhất, và đó cũng là lúc những chi tiết hữu ích nhất biến mất. Ghi lại thời điểm, các cửa sổ đang mở và liệu menu mạng có hiển thị kết nối trước khi khởi động lại; những quan sát đó tồn tại qua lần khởi động lại dù trạng thái tiến trình thì không.

Khi máy trở lại, hãy chống lại kết luận rằng lần khởi động lại đã tìm ra thủ phạm. Nó khôi phục dịch vụ và không nêu tên gì cả. Chỉ một lần lặp lại với một thay đổi được kiểm soát mới có thể chỉ ra một thành phần.

Nếu tình trạng treo quay lại, hãy đổi một điều kiện mỗi lần thử: mạng, phiên bản ứng dụng khách hoặc chế độ ngủ. Lưu công việc từ xa trước, và tránh lặp lại giấc ngủ cưỡng bức trên máy sản xuất, vì các chu kỳ cứng lặp lại có nguy cơ mất dữ liệu và thường tạo ra lỗi khác với lỗi bạn đang theo đuổi. Ghi lại từng lần thử cùng các điều kiện của nó để lần sau có thể so sánh chứ không phải giai thoại.

Bàn giao một sự kiện, không phải một tâm trạng

Việc bàn giao tạo ra hành động nêu bốn điều: cái gì ngừng phản hồi, khi nào xảy ra, mạng trông thế nào vào lúc đó, và cách ghi nào bao trùm khoảng thời gian ấy. Thêm phiên bản ứng dụng khách và bản dựng macOS, rồi dừng lại. Cả nhóm nền tảng và nhà cung cấp ứng dụng khách đều có thể hành động dựa trên câu đó, và không bên nào có thể hành động dựa trên một mô tả bực bội. Giữ hồ sơ ở một nơi và bổ sung vào đó thay vì kể lại câu chuyện mỗi lần; nếu một bản cập nhật đã thay đổi hành vi, hãy nêu bản nào, vì đó cũng là bằng chứng.

Một hồ sơ tốt cũng nói rõ điều bạn đã loại trừ. Nếu một ứng dụng cục bộ phản hồi trong lúc treo, hãy nói ra; nếu nhật ký ngủ cho thấy thức dậy thật chứ không phải khóa, cũng hãy nói ra. Người tiếp theo không nên phải lặp lại những phép thử bạn đã làm.

Trước khi đóng phiếu, hãy kiểm tra ba điều: dấu thời gian đến từ nhật ký ngủ chứ không phải từ ký ức, cách ghi khớp với triệu chứng bạn thực sự thấy, và gói dữ liệu nằm ở vị trí đã được phê duyệt. Nếu thiếu bất kỳ điều nào trong ba, báo cáo chưa sẵn sàng để gửi.