键盘鼠标无法唤醒系统，根本原因是内核未正确加载唤醒设备白名单，USB主机控制器（如usb1、pci0000:00/0000:00:14.0）等关键设备的wakeup属性默认为disabled，且ACPI唤醒事件未被systemd-logind正确路由，需通过BIOS设置、内核参数（acpi_enforce_resources=lax、acpi_osi=Linux）及持久化udev规则协同修复。
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 处理状态：
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 启停。这点容易被忽略：唤醒后图形会话可能仍锁屏，但服务已恢复，业务逻辑却卡在等待用户解锁上。
