键盘或鼠标无法唤醒系统，根本原因通常是内核没有正确加载可唤醒设备白名单，导致 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 之后，都会遇到一个非常常见的问题：按键盘没有反应、移动鼠标也没有反应，甚至短按电源键都无法唤醒电脑。这一般不是 suspend 命令本身有问题，真正的原因通常在于当前 Linux 内核没有把唤醒设备白名单正确加载。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/ 中显示的真实设备路径完全一致；而且该设置在系统重启后会失效，所以只能用于临时测试，不能作为长期解决 Ubuntu 无法睡眠唤醒的问题方案。
如何让合盖/电源键真正触发唤醒
如果遇到合盖后无法唤醒，或者电源键失灵，本质原因通常是 ACPI 事件没有被正确路由到 systemd-logind 或内核电源管理子系统。关键点并不在桌面环境的电源设置，而在于底层固件、ACPI 支持与内核参数之间是否配合正常。
验证当前 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（某些机型下这两个选项会影响 USB 唤醒或 ACPI 唤醒路径） - 在
/etc/default/grub中追加内核参数：acpi_enforce_resources=lax acpi_osi=Linux，然后执行sudo update-grub && sudo reboot
特别要注意：acpi_osi=Linux 对 Dell、Lenovo 等笔记本的睡眠唤醒成功率提升通常比较明显，但也有可能影响显卡热插拔等其他硬件功能，因此需要结合实际机器进行测试。
rtcwake 定时唤醒总失败？检查这三处硬限制
rtcwake 看起来用法简单，但在实际使用中经常会因为硬件限制或权限链路异常而“静默失败”——它可能不报错，却会出现“系统睡下去之后再也没有自动唤醒”的情况。排查这类 Linux 定时唤醒失败问题时，建议优先检查以下三点：
- 确认 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，说明 BIOS 已禁用 S3 深度睡眠，此时rtcwake -m mem基本一定会失败
实用技巧：可以使用 -m no 模式，只设置 alarm 而不真正挂起系统，再配合 journalctl -u systemd-suspend.service -n 50 查看唤醒后 systemd 是否接收到了 resume 事件——这是判断“系统是否真正被唤醒”还是“出现假唤醒”的最可靠方法之一。
systemd 服务如何响应唤醒事件而不重复启动
如果直接把 WantedBy=resume.target 写进 service 文件中，这是一个非常典型、也非常容易踩坑的做法。原因在于，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的特点是仅在服务已停止时才启动，否则会直接跳过
更稳妥的方案，是让主服务自己监听 org.freedesktop.login1.Session.Lock 和 org.freedesktop.login1.Manager.Resume 这类 D-Bus 信号，再通过 Python 或 bash 调用 loginctl unlock-session 或执行配置重载，而不是完全依赖 systemd 启停机制。这个细节很容易被忽视：系统唤醒后，图形会话可能依旧处于锁屏状态，虽然服务已经恢复运行，但业务逻辑却可能卡在等待用户解锁这一步，最终表现为“看起来已经唤醒，实际功能仍不可用”。
