问题背景
这个春节期间，最火的无疑是 OpenClaw，于是我打算再折腾吃灰已久的 HP EliteDesk 800 G4（介绍），安装了 Ubuntu 24.04。 为了省电，将其配置为 multi-user.target（纯文本模式）作为无头服务器（Headless Server）使用。但在实际运行中遇到了非常诡异的现象：
- 现象 A：机器空置一段时间后，SSH 无法连接，Ping 不通。
- 现象 B：以为机器卡死，手动按了一下物理电源键想唤醒，结果系统直接触发了正常关机。
- 现象 C：重启后通过 uptime 发现系统运行时间不对，之前的 tmux 会话全部丢失，说明系统曾发生过非预期的重启。
1# 配置 TUI 登录
2sudo systemctl set-default multi-user.target
3# 配置 GUI 登录
4sudo systemctl set-default graphical.target第一阶段：锁定“逻辑休眠”
- 分析：手动按电源键会触发优雅关机（Graceful Shutdown），证明系统在按键前并没有死机，而是进入了休眠/挂起状态。
- 操作：禁用系统级休眠单元。为了彻底切断系统自动休眠的路径，执行了以下屏蔽操作：
1# 1. 屏蔽所有系统级的休眠和挂起目标，确保系统在逻辑上“不能睡”
2sudo systemctl mask sleep.target suspend.target hibernate.target hybrid-sleep.target
3
4# 2. 同时修改电源键行为，防止排查时误按导致关机（可选）
5# 编辑 /etc/systemd/logind.conf 设置 HandlePowerKey=ignore
6
7# 3. 重启 logind 服务使配置生效
8sudo systemctl restart systemd-logind第二阶段：初战告败，聚焦“网卡省电”
- 挫折：即便屏蔽了所有休眠目标，机器空闲一段时间后依然会 Ping 不通。诡异的是，只要物理接上显示器并登录，网络就会瞬间恢复。
分析：这说明即便系统没进入 Suspend，网卡硬件层面的省电策略（Power Management）依然在闲置时切断了连接。
1# 1. 查看当前 WiFi 省电状态 2iwconfig # 如果是 WiFi，查看 Power Management 是否为 on 3# 2. 如果是以太网，使用 ethtool 查看是否启用了省电功能 4sudo ethtool [网卡名] # 查看 Wake-on-LAN (WOL) 状态操作：禁用 WiFi 功率管理。
1sudo vim /etc/NetworkManager/conf.d/default-wifi-powersave-on.conf 2# 将 wifi.powersave = 3 改为 2（禁用省电）。- 反馈：修改后，SSH 掉线频率降低，但依然存在“假死”后重启的情况。
第三阶段：通过日志定位“真凶”——i915 驱动
核心矛盾：虽然优化了网卡，SSH 也能登录系统，但是 uptime 显示系统仍会随机重启，之前启动的 tmux 会话也会丢失，说明系统仍然存在“假死”现象。
1# 查看机器重启时间 2# last reboot -F 命令也可以 3$ journalctl --list-boots 4 5IDX BOOT ID FIRST ENTRY LAST ENTRY 6-28 af289f3447154097bb3f0c98b6b7a5b0 Sun 2026-02-15 21:09:56 CST Sun 2026-02-15 21:15:37 CST 7-27 9c32ddd701a24686835fcd6023302d12 Sun 2026-02-15 21:43:20 CST Sun 2026-02-15 22:04:07 CST 8-26 4a7ccbf999f4438f9e0d10fcbb602ba4 Sun 2026-02-15 22:04:28 CST Sun 2026-02-15 22:30:07 CST 9-25 e9391f3d149448868fa9d7ffd1fb5a7a Sun 2026-02-15 22:30:32 CST Sun 2026-02-15 22:34:34 CST 10-24 00d86ee93ba640d8b38417e6362db978 Sun 2026-02-15 22:34:53 CST Mon 2026-02-16 01:35:01 CST 11... 12 -1 9bc03b0c081a412394f036a41f13e807 Tue 2026-02-17 21:46:25 CST Wed 2026-02-18 08:30:11 CST 13 0 6e360a82db93468ba09cd6f8e44eb95e Wed 2026-02-18 08:30:31 CST Wed 2026-02-18 10:10:03 CST 14 15# IDX 0 是当前启动时间，-1 即为上次重启时间 16# 使用下面命令查看上次启动时，最后的 100 行日志 17journalctl -b -1 -n 100深度排查（查看“死前”最后时刻）：通过
journalctl -b -1 -n 100查看上一次系统崩溃重启前的最后日志，发现了关键报错：1Feb 17 18:00:05 devbox systemd[1]: sysstat-collect.service: Deactivated successfully. 2Feb 17 18:00:05 devbox systemd[1]: Finished sysstat-collect.service - system activity accounting tool. 3Feb 17 18:00:12 devbox systemd[1225]: Started snap.firmware-updater.firmware-notifier.service - Service for snap application firmware-updater.firmware-notifier. 4Feb 17 18:00:12 devbox kernel: audit: type=1400 audit(1771322412.494:160): apparmor="DENIED" operation="open" class="file" profile="snap.firmware-updater.firmware-notifier" name="/p> 5Feb 17 18:00:58 devbox kernel: workqueue: i915_hpd_poll_init_work [i915] hogged CPU for >10000us 1027 times, consider switching to WQ_UNBOUND 6Feb 17 18:05:01 devbox CRON[7460]: pam_unix(cron:session): session opened for user root(uid=0) by root(uid=0) 7Feb 17 18:05:01 devbox CRON[7461]: (root) CMD (command -v debian-sa1 > /dev/null && debian-sa1 1 1) 8Feb 17 18:05:01 devbox CRON[7460]: pam_unix(cron:session): session closed for user root- 真相大白：i915 驱动 Bug：这是 Intel 集成显卡驱动。HPD Poll 轮询：当不接显示器运行时，驱动会不断进行 HPD（Hot Plug Detect，热插拔检测） 轮询，尝试寻找显示器。
- 假死原因：在某些硬件（如 HP EliteDesk）上，这种轮询会长时间霸占 CPU（Hogged CPU），导致内核死锁（Hard Lockup），进而引发网络中断（Ping 不通）并最终触发系统保护性重启。
终极解决方案：彻底禁用显卡驱动
由于该机器作为 Headless 服务器使用，完全不需要 GPU 显示能力。为了追求极致稳定性，直接选择“黑名单”化显卡驱动。 操作步骤： 创建驱动黑名单文件：
1sudo bash -c 'cat > /etc/modprobe.d/blacklist-i915.conf << EOF
2blacklist i915
3blacklist intel_agp
4EOF'更新内核镜像（initramfs）并重启：
1sudo update-initramfs -u -k all
2sudo reboot
3
4# 重启后，检查 i915 是否加载
5lsmod | grep i915内核启动时不再加载 i915 驱动，彻底消除了显卡硬件轮询带来的 CPU 占用和系统死锁，我的问题得到彻底解决。
经验总结
在这次长达数天的“猫鼠游戏”中（每次验证需要闲置数小时），我总结了几条比命令本身更重要的调优经验：
- 不要被“死机”的表象欺骗
- 当你发现 SSH 连不上、Ping 不通时，第一反应往往是“系统崩了”。但如果按一下电源键机器还能正常关机，说明系统内核还没死，它只是“睡得太死”或“忙着找显示器”。这时候，查日志比盲目重启更有用。
- “无头”模式（Headless）是稳定性的试金石
- 很多微型机（如 HP EliteDesk、Intel NUC）在设计时默认你是接显示器用的。一旦拔掉显示器，显卡驱动就会像一个找不到孩子的母亲一样疯狂“轮询”接口，最终把 CPU 资源耗尽。做服务器用的机器，如果不打算转码，禁用显卡驱动是最高级的稳重。
- 省电模式是服务器的天敌
- 在 Linux 的世界里，省电往往意味着牺牲响应速度。无论是 WiFi 的 powersave，还是 CPU 的 C-States，亦或是网卡的 ASPM，这些在笔记本上续航的功臣，在服务器上都是掉线和延迟的罪魁祸首。作为服务器，第一准则是：永远不要让硬件尝试省电。
- 让日志拥有“记忆”
- Ubuntu 默认的日志重启即丢。如果没有手动开启 journald 的持久化存储（Persistent Storage），我永远不会看到那行关键的 i915 hogged CPU。排查问题的第一步，永远是确保你能看到“死前”的遗言。
- 尊重物理按键的信号
- 把电源键改成 ignore 是最后的尊严。它让你在绝望地尝试唤醒服务器时，不至于因为一次无奈的按压而彻底失去正在运行的进程。
延伸阅读：如果你还需要 GPU 能力怎么办？
如果你不想像我一样彻底禁用驱动（例如需要跑 Jellyfin 视频转码或 AI 计算），可以尝试以下进阶方案：
- 方案 A：手术刀式内核参数（此方案我尝试失败，需进一步研究）。
不禁用驱动，但关闭死锁逻辑。在
/etc/default/grub中添加：1GRUB_CMDLINE_LINUX_DEFAULT="quiet splash i915.enable_dc=0 i915.enable_psr=0 i915.enable_fbc=0 drm.debug=0x00"quiet- 启动时隐藏大部分内核日志信息splash- 显示图形启动画面代替文字滚动i915.enable_dc=0- 禁用 Intel 显卡的深度睡眠节能模式i915.enable_psr=0- 禁用面板自刷新功能（显示器自己刷新画面不需要 GPU 持续发送数据）i915.enable_fbc=0- 禁用显存帧缓冲压缩功能drm.debug=0x00- 关闭显卡驱动框架的调试日志输出
之后执行
1sudo update-grub 2sudo reboot 3# 重启进入系统后，使用以下命令检查当前运行的内核参数： 4cat /proc/cmdline- 方案 B：硬件“欺骗”法（显卡欺骗器）
- 花十几块钱买个 HDMI 虚拟显示器（Dummy Plug） 插在主机上。让驱动认为始终连着显示器，从而停止疯狂轮询。
- 方案 C：禁用 BIOS 中的深度省电
- 进入 HP BIOS (F10) -> Advanced -> Power Management Options，关闭 Extended Idle Power States 和 S5 Maximum Power Savings。