pm-utils 是已废弃的系统级电源事件脚本框架，用于在 suspend/hibernate/resume 时执行硬件相关钩子，不管理进程状态；进程休眠唤醒由内核透明处理，无需用户干预。
Linux 中的 pm-utils 并不用于“管理进程在休眠唤醒后的状态”，它是一个已废弃的、面向系统级电源事件（如 suspend/hibernate/resume）的脚本框架，本身不跟踪、恢复或控制用户进程行为。进程在休眠唤醒后的状态，由内核透明处理：休眠时内存被冻结并写入磁盘（hibernate）或保持供电（suspend），唤醒后内核直接恢复执行上下文，绝大多数进程无感知、无需额外干预。
pm-utils 的真实作用与现状
pm-utils 提供的是在系统进入休眠（suspend）、休眠到磁盘（hibernate）或从它们恢复（resume）时，自动调用自定义钩子脚本的机制。这些钩子常用于：
- 暂停/重启硬件相关服务（如蓝牙、WiFi 驱动重载）
- 同步或临时保存易失性状态（如某些音频缓冲、GPU 上下文）
- 关闭/重置外设（如 USB 设备、触摸屏校准）
- 通知桌面环境触发 UI 层响应（如锁屏、刷新显示）
它不启动、停止、重启普通应用进程（如 Firefox、VS Code），也不保存/恢复进程内存或打开的文件句柄——那是内核和应用程序自身需协作完成的事。
为什么你不该用 pm-utils 管理进程状态
试图用 pm-utils 脚本去“保存进程状态”存在根本性问题：
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
-
进程不可序列化：大多数进程（尤其是带 GUI、网络连接、共享内存、信号处理的）无法被安全地 dump 和 restore，
pm-utils没有类似 CRIU 的检查点能力 - 时机不可靠：resume 钩子在内核恢复后运行，但此时图形会话可能尚未就绪，X/Wayland 服务未响应，导致脚本失败
- 权限与上下文缺失：resume 钩子以 root 运行，无法访问用户会话的 D-Bus、X11 socket 或 systemd --user 实例，无法操作用户级进程
-
已被现代方案替代：systemd 已全面接管电源管理，通过
systemd-suspend.service及sleep.target依赖机制实现更可靠、可审计的挂起流程
真正需要关注的进程行为场景及建议
若你观察到休眠唤醒后某些进程异常（如音频中断、网络断连、窗口错位、应用崩溃），应按以下思路排查：
-
检查驱动与固件：运行
dmesg | grep -i "error\|warn\|acpi"，重点关注显卡（i915/amdgpu/nouveau）、WiFi（iwlwifi/rtw88）、USB 控制器日志 -
确认桌面环境集成：GNOME/KDE 通常自带 resume 处理逻辑（如重新加载屏幕缩放、通知服务），确保未禁用
gnome-session或plasmashell的电源事件监听 - 应用自身恢复能力：浏览器、编辑器等现代应用普遍支持会话恢复（通过本地存储或配置文件），检查其设置中是否启用 “Restore previous session”
-
避免手动 kill 进程后休眠：若在 suspend 前手动终止了关键服务（如
pipewire、NetworkManager），resume 后不会自动拉起，应交由 systemd 管理其生命周期
如仍需兼容旧系统：最小化钩子示例
仅当必须适配老旧发行版（如 Debian 9、Ubuntu 16.04）且遇到特定硬件问题时，才考虑编写 /etc/pm/sleep.d/99-my-fix：
#!/bin/sh
case "$1" in
thaw|resume)
# 仅限 root 可执行的操作，例如：
systemctl try-restart bluetooth 2>/dev/null
modprobe -r i2c_i801 && modprobe i2c_i801 2>/dev/null
;;
esac
注意：不要在此处调用 su -u $USER ... 或 dbus-run-session，这类做法极不稳定；用户级恢复逻辑应放在桌面自动启动项或 systemd user timer 中。
休眠唤醒是内核与硬件协同完成的底层状态切换，进程层面的“状态管理”不是 pm-utils 的职责，也不应由它承担。聚焦驱动兼容性、桌面环境配置和应用自身恢复机制，才能解决实际问题。
