Điều gì đang khiến Mac của bạn không ngủ? Đây là cách tìm ra

Power assertion của macOS hoạt động như thế nào

macOS không chỉ ngủ theo một bộ đếm ngược đơn thuần. Trước khi làm tối màn hình hay cho ổ đĩa ngừng quay, kernel sẽ kiểm tra xem có process nào đang giữ một power assertion hay không — một yêu cầu được gửi qua framework quản lý năng lượng IOKit, báo cho hệ thống biết nó cần được giữ thức. macOS tôn trọng yêu cầu đó cho đến khi process giải phóng nó hoặc process kết thúc.

Có hai loại assertion chiếm phần lớn hành vi ngủ của máy. PreventUserIdleSystemSleep chặn Mac ngủ hoàn toàn — ổ đĩa, màn hình, mọi thứ. PreventUserIdleDisplaySleep chỉ giữ màn hình sáng và để phần còn lại của hệ thống ngủ nếu nó muốn. Một trình quản lý tải xuống, một trình phát video, caffeinate chạy từ Terminal, hay một app giữ Mac không ngủ như LidRun đều có thể giữ một trong hai loại này, mỗi cái vì một lý do khác nhau.

Assertion không phải lỗi — đó là một tính năng được thiết kế có chủ đích, và cùng một cơ chế có thể có hai mặt. Lock giữ Mac thức suốt một tác vụ AI chạy qua đêm chính là cơ chế y hệt mà một tab trình duyệt bị bỏ quên dùng để giữ máy thức sau khi video đã dừng phát từ lâu. Mục tiêu không phải là nghi ngờ mọi assertion; mà là biết được cái nào bạn chủ động yêu cầu, cái nào tự dưng xuất hiện mà không ai mời.

Dùng Activity Monitor để tìm nguyên nhân

Mở Activity Monitor từ Applications → Utilities, hoặc tìm bằng Spotlight. Bấm vào tab Energy. Cột Preventing Sleep hiện Yes hoặc No cho từng process mà hệ thống đang theo dõi — bấm vào tiêu đề cột để sắp xếp các assertion đang hoạt động lên đầu.

Những bất ngờ thường gặp trong danh sách đó: một tab trình duyệt có video đang tạm dừng, một app đồng bộ cloud đang giữa chừng tải lên, một bản sao lưu Time Machine vẫn chạy ngầm, một app podcast, hay một cuộc gọi video vẫn mở dù bạn đã rời phòng họp từ lâu. Nhấp chuột phải vào mục nào đáng ngờ rồi chọn Inspect Process để xem đường dẫn binary đầy đủ và process cha của nó — thường thì vậy là đủ để xác định.

Activity Monitor là một bước kiểm tra đầu tốt, nhưng nó vẫn có điểm mù. Các công cụ CLI và daemon chạy ngầm — kể cả caffeinate khởi chạy từ Terminal — đôi khi xuất hiện dưới một cái tên chung chung, hoặc không hiện trong danh sách chút nào. Với những trường hợp đó, lệnh Terminal bên dưới sẽ cho bức tranh đầy đủ hơn.

Đọc kết quả pmset -g assertions trong Terminal

Mở Terminal và chạy pmset -g assertions. Kết quả liệt kê mọi power assertion đang hoạt động trên hệ thống: loại assertion, tên dễ đọc mà app đặt cho nó, và process ID đã tạo ra nó. Một khối tóm tắt ở đầu chia chúng thành Listed (đang hoạt động) và Timed Out (bộ đếm giờ đã hết, nhưng app chưa bao giờ gọi release).

Một assertion đã timed out vẫn có thể chặn máy ngủ — process đó đặt một deadline, deadline đã trôi qua, nhưng bản thân cái lock thì chưa bao giờ được giải phóng. Nếu một PID trong kết quả trông lạ, đối chiếu nó với ps aux | grep, theo sau là PID đó, để xác nhận nó thuộc về process nào. Một số assertion có timeout rõ ràng; số khác thì vô thời hạn — một PreventUserIdleSystemSleep vô thời hạn do một agent chạy ngầm bị treo hoặc crash giữ lại sẽ khiến Mac thức mà không có nguyên nhân rõ ràng nào, và đây là điều đầu tiên đáng kiểm tra nếu máy đã bật lâu hơn nhiều so với dự kiến.

pmset -g assertions chỉ cho thấy những gì đang hoạt động ngay lúc này — nó không có bộ nhớ lịch sử. Hai lệnh liên quan sẽ lấp khoảng trống đó. pmset -g thuần (không kèm cờ assertions) có một dòng SleepDisabled — một cài đặt toàn cục khác, mà một số công cụ, cùng với chế độ Closed-Lid của chính LidRun, bật lên bằng pmset -a disablesleep thay vì tạo một assertion thông thường (phần sau sẽ nói kỹ hơn). Còn pmset -g log in ra dòng thời gian lịch sử của các sự kiện ngủ, thức và assertion, hữu ích nếu bạn muốn biết điều gì đã giữ Mac thức suốt đêm qua thay vì ngay bây giờ.

Để dừng một assertion CLI như caffeinate, tìm PID của nó trong kết quả pmset rồi chạy kill kèm theo PID đó. Thoát một app cũng giải phóng assertion của nó ngay lập tức — assertion thông thường gắn liền với process, nên macOS xóa chúng ngay khi process kết thúc, không cần thêm bước dọn dẹp nào. Nếu một assertion không rõ chủ, hoặc process của nó đã crash từ trước, khởi động lại máy sẽ xóa sạch mọi lock còn tồn đọng.

Khi pmset -g assertions trả về rỗng

Đôi khi pmset -g assertions trả về hoàn toàn rỗng, nhưng Mac vẫn có cảm giác như chưa bao giờ tắt hẳn — quạt quay lên rồi giảm xuống, hoặc màn hình nhấp nháy sáng lên mà chẳng thấy app nào. Đó thường không phải một assertion ẩn; mà là một dark wake theo lịch. macOS định kỳ thức dậy trong chốc lát để làm các tác vụ mạng — đồng bộ iCloud, Find My, Handoff, và Power Nap — dù chẳng có gì giữ lock cả, rồi tự quay lại ngủ vài giây sau đó.

Nếu muốn loại trừ khả năng này, vào System Settings → Battery → Options và tắt Wake for network access. Nó sẽ không ngăn được một assertion thật sự — nếu có thứ gì đó đang thực sự tạo PreventUserIdleSystemSleep, cài đặt này không đụng tới nó — nhưng nó loại bỏ được tiếng ồn nền, giúp lần kiểm tra pmset -g assertions tiếp theo dễ đọc hơn.

Đây cũng là lúc nên kiểm tra pmset -g thuần để tìm dòng SleepDisabled: 1 đã nói ở trên. Nó sẽ không xuất hiện trong pmset -g assertions vì đó không phải là một assertion — mà là một cài đặt hệ thống thường trực, phần lớn bị để quên ở trạng thái bật bởi pmset -a disablesleep từ một script, một công cụ bên thứ ba, hoặc một app (kể cả chế độ Closed-Lid của LidRun) đã crash trước khi kịp tự tắt nó đi.

Assertion có chủ đích và assertion không mong muốn

Không phải assertion nào cũng cần bị gỡ bỏ. Nếu bạn đang chạy một phiên Claude Code dài, một tác vụ model cục bộ, hay một Cursor agent chạy qua đêm, thì phải có thứ gì đó giữ assertion đó — kill nó đi cũng đồng nghĩa với việc giết luôn công việc của bạn. Câu hỏi thật sự không chỉ là 'vì sao Mac của tôi vẫn thức' mà là 'tôi có yêu cầu điều này không'.

Một trình quản lý tải xuống giữ chặn ngủ cho đến khi việc truyền file hoàn tất là đang làm đúng việc của nó. Một trình phát video giữ chặn sau khi bạn đã đóng cửa sổ thì không. Một công cụ bạn chủ động cấu hình — LidRun, caffeinate -i chạy bằng tay — là có chủ đích. Một tab trình duyệt với video tạm dừng mà bạn đã quên mất thì không. Điểm khác biệt nằm ở sự đồng ý, không phải ở cơ chế.

Nếu câu trả lời của bạn là 'đúng vậy, tôi muốn điều này', thì bạn đã có sẵn các lựa chọn miễn phí, có sẵn trong hệ thống. caffeinate -i, chạy từ Terminal, tạo ra đúng assertion PreventUserIdleSystemSleep đã nói ở trên trong suốt thời gian lệnh còn chạy — thêm -t 3600 để giới hạn tối đa một giờ. Nó gắn liền với process, nên kết thúc lệnh hoặc đóng cửa sổ Terminal sẽ tự động giải phóng nó. Tuy nhiên caffeinate không giúp được gì với lid đóng — một assertion idle-sleep không chạm tới clamshell sleep. Đòn bẩy miễn phí duy nhất ở đó là sudo pmset -a disablesleep 1, và nó hoạt động khác đi một cách có chủ đích: đây là một cài đặt toàn cục, thường trực chứ không gắn với process, nên nó vẫn tồn tại kể cả khi app đã đặt nó bị crash, và giữ nguyên trạng thái bật cho đến khi có thứ gì đó chạy hẳn pmset -a disablesleep 0 hoặc Mac khởi động lại. Các app trên menu bar như Amphetamine, KeepingYouAwake, Lungo, và Caffeine bọc cùng một cơ chế nền tảng đó trong một công tắc bật-tắt một chạm, và đó là lựa chọn hoàn toàn ổn nếu bạn chỉ cần một công tắc thủ công. Dù theo cách nào, bên dưới vẫn là cùng một assertion hoặc cùng một cờ disablesleep — đó chính là lý do vì sao biết pmset -g assertions luôn đáng giá, bất kể công cụ nào đã tạo ra lock đó. So sánh LidRun với caffeinate đi qua toàn bộ chi phí và tính năng.

Với một lock bạn muốn giữ nhưng giữ một cách an toàn, điều thật sự quan trọng là các lớp bảo vệ: tự động dừng trước khi pin xuống mức nguy hiểm, nhận biết trạng thái nhiệt để một chiếc Mac đang nóng không bị giữ thức vô thời hạn, và giới hạn assertion vào đúng một tác vụ để nó tự giải phóng ngay khi tác vụ kết thúc thay vì trông chờ vào trí nhớ của bạn. Auto Mode của LidRun xử lý phần giới hạn đó: chỉ định một tên process — một phiên Claude Code, một bản build, một tác vụ render — và nó chỉ giữ assertion trong lúc process đó đang chạy, rồi giải phóng ngay khi process thoát. Agent đang chạy thì giữ thức; agent xong việc thì giải phóng — đó là toàn bộ thiết kế, không phải một wake lock mù quáng để nguyên đó cho đến khi ai đó nhớ ra mà tắt đi. Hướng dẫn tự động giữ thức, chỉ khi đang làm việc đi sâu vào mẫu hình này. Khi chạy bằng pin, LidRun cũng tự dừng khi xuống dưới một ngưỡng — mặc định 20%, có thể chỉnh từ 15% đến 50% — bất kể lúc đó còn gì đang chạy, và tự thoát khỏi chế độ Closed-Lid ngay khi hệ thống báo áp lực nhiệt ở mức nghiêm trọng (kèm cảnh báo ở mức nghiêm trọng trước đó), vì lid đóng chặn đường tản nhiệt chính của Mac, và không có mức độ tự động hóa nào nên giữ lid đóng trong lúc máy đang quá nóng.

Khi thủ phạm là thứ không mong muốn, thoát app đó sẽ xử lý ngay lập tức. Nếu cùng một process cứ tái xuất hiện sau mỗi lần khởi động lại, kiểm tra System Settings → General → Login Items và Background Items để tìm các agent được đặt tự khởi chạy. Gỡ bỏ hoặc tắt login item đó sẽ chặn đứng vòng lặp ngay từ gốc.