Ubuntu如何设置系统睡眠唤醒策略-LINUX-PHP中文网

键盘鼠标无法唤醒系统，根本原因是内核未正确加载唤醒设备白名单，usb主机控制器（如usb1、pci0000:00/0000:00:14.0）等关键设备的wakeup属性默认为disabled，且acpi唤醒事件未被systemd-logind正确路由，需通过bios设置、内核参数（acpi_enforce_resources=lax、acpi_osi=linux）及持久化udev规则协同修复。

ubuntu如何设置系统睡眠唤醒策略

systemctl suspend 之后为什么键盘鼠标没反应

多数人执行 systemctl suspend 后，发现按键盘、动鼠标、甚至短按电源键都没反应，不是命令错了，而是当前内核未正确加载唤醒设备白名单。Ubuntu 默认只允许部分设备（如某些 USB 键盘）唤醒系统，而很多外接键鼠、蓝牙设备或触摸板默认被忽略。

检查当前允许唤醒的设备：

cat /sys/power/wakeup

查看每个设备的 wakeup 属性是否为 enabled。常见问题设备包括：

usb1、usb2 等 USB 主机控制器（而非具体键鼠设备）
0000:00:14.0 类似 PCI 设备名，对应 USB 3.x 控制器
pci0000:00 或 platform:gpio-keys（笔记本盖合/开盖事件）

临时启用某设备唤醒（需 root）：

echo enabled > /sys/devices/pci0000:00/0000:00:14.0/power/wakeup

⚠️ 注意：路径必须精确匹配 ls /sys/devices/ 下真实设备路径；重启后失效，不能靠改这个解决长期问题。

如何让合盖/电源键真正触发唤醒

合盖不唤醒、电源键失灵，本质是 ACPI 事件未被正确路由到 systemd-logind 或内核电源子系统。关键不在桌面环境设置，而在底层固件与内核参数协同。

验证当前 ACPI 处理状态：

Linux Distros

Linux发行版游乐场，适用于需要临时Linux沙箱、基于浏览器的Linux虚拟机、一次性终端环境、桌面Linux会话等场景

下载

sudo dmesg | grep -i "acpi.*wakeup\|wakeup.*enabled"

若输出极少或含 ACPI: No _PRW object found，说明 BIOS 没暴露唤醒能力，或内核未识别。此时可尝试：

进 BIOS/UEFI，开启 Wake on RTC Alarm、Power On by PCI-E/USB、Deep Sleep Control（名称因厂商而异）
禁用 Fast Boot 和 Secure Boot（部分机型下二者会屏蔽唤醒路径）
在 /etc/default/grub 中追加内核参数：acpi_enforce_resources=lax acpi_osi=Linux，再运行 sudo update-grub && sudo reboot

特别注意：acpi_osi=Linux 对 Dell、Lenovo 笔记本唤醒成功率提升明显，但可能影响显卡热插拔等其他功能，需实测。

rtcwake 定时唤醒总失败？检查这三处硬限制

rtcwake 看似简单，但实际常因硬件或权限链断裂而静默失败——它不报错，只是“睡过去就再也不醒”。排查优先级如下：

确认 RTC 设备支持 alarm 功能：sudo hwclock --show 成功 ≠ alarm 可用；执行 sudo rtcwake -m mem -s 10 -v，观察输出末尾是否有 alarm: set to ... 和 RTC time is ... 两行
检查 /dev/rtc0 权限：ls -l /dev/rtc*，若属组不是 root:root 或权限非 crw-------，需添加 udev 规则或临时 sudo chmod 666 /dev/rtc0
确认当前挂起模式被硬件支持：cat /sys/power/state 输出中必须含 mem（suspend）或 disk（hibernate）；若只有 freeze，说明 S3 深度睡眠被 BIOS 禁用，rtcwake -m mem 必然失败

实用技巧：用 -m no 模式仅设 alarm 不挂起，配合 journalctl -u systemd-suspend.service -n 50 查看唤醒后 systemd 是否收到 resume 事件——这是判断唤醒“成功”还是“假醒”的唯一可靠依据。

systemd 服务如何响应唤醒事件而不重复启动

直接在 service 文件里写 WantedBy=resume.target 是常见误区：resume.target 是瞬态目标，每次唤醒都触发，但若服务已运行，systemd 不会二次启动，也不会自动 restart——它只是“通知已到达”，你得自己处理状态。

正确做法分两步：

主服务保持 Type=simple 或 Type=forking，并设置 Restart=on-failure（非 always），避免唤醒时强行重启正在运行的进程
另写一个 .target 或 .service 单元监听 resume.target，用 ExecStart=/bin/sh -c 'systemctl try-restart your-main-service.service' ——try-restart 仅当服务已 stop 才启动，否则跳过

更稳妥的方案是让主服务自身监听 org.freedesktop.login1.Session.Lock 和 org.freedesktop.login1.Manager.Resume D-Bus 信号，用 Python 或 bash 调用 loginctl unlock-session 或重载配置，而不是依赖 systemd 启停。这点容易被忽略：唤醒后图形会话可能仍锁屏，但服务已恢复，业务逻辑却卡在等待用户解锁上。