Debian 13 Headless 无头服务器
背景
最近把一台淘汰的台式机（Intel i5-8500 CPU / 16G RAM）刷成 Debian 13（Trixie）测试版，拔掉显示器和键盘，以 Headless 模式作为家里的无线小型服务器使用。
配置好服务后，机器每隔 1～2 个小时就会“失联”，SSH 连接超时。重新物理开机登录后，发现后台常驻的 tmux 会话和正在运行的应用服务都消失了。
初步看起来，机器可能发生了自动关机或硬件崩溃（Kernel Panic）。
第一阶段：排查日志
由于没有显示器输出，只能登录系统后，通过历史记录和内核日志分析问题。
1. last reboot 中的崩溃记录
执行 last reboot，系统给出了以下记录：
reboot system boot 6.12.86+deb13-am Mon Oct 5 10:37 - still running
reboot system boot 6.12.86+deb13-am Sun Oct 4 23:13 - crash
reboot system boot 6.12.86+deb13-am Sun Oct 4 22:54 - crash
reboot system boot 6.12.86+deb13-am Sun Oct 4 16:08 - crash
这些 crash 字样容易误导。Linux 的 last 并不是在死机瞬间写入 crash，而是在下一次开机时根据上一次是否正常关机反向推断。如果 SSH 无法连接后直接按下电源键或拔掉电源，系统下次启动时发现上一次没有正常关机记录，就会标记为 crash。因此，这些记录本身不能证明系统确实发生了崩溃。
2. 全量日志中断
查看失联前的 journalctl 全量系统日志，发现了三组值得关注的现象。
证据一：网络连接频繁变化，主机名被反复刷新
异常日志
Oct 04 16:02:23 localhost NetworkManager[804]: policy: set-hostname: set hostname to 'MiWiFi-RD16-srv' (from DHCPv4)
Oct 04 16:02:23 localhost systemd[1]: Starting NetworkManager-dispatcher.service...
Oct 04 16:02:33 localhost systemd[1]: NetworkManager-dispatcher.service: Deactivated successfully.
Oct 04 16:02:36 localhost NetworkManager[804]: policy: set-hostname: set hostname to 'MiWiFi-RD16-srv' (from DHCPv4)
Oct 04 16:03:01 localhost NetworkManager[804]: policy: set-hostname: set hostname to 'MiWiFi-RD16-srv' (from DHCPv4)
分析
默认情况下，Debian 的 NetworkManager 通过无线网络续约 DHCP 时，会向路由器请求推荐的主机名。无头模式下无线网卡存在轻微信号波动时，NetworkManager 可能频繁刷新网络状态并重写主机名。这种变化会干扰网络长连接，并导致 SSH 会话断开。
解决方法
修改 /etc/NetworkManager/NetworkManager.conf，在 [main] 标签下增加以下配置，禁止 NetworkManager 修改主机名：
[main]
hostname-mode=none
hostname-mode=none 会让 NetworkManager 停止根据 DHCP 提供的信息设置系统主机名。这样，主机名由本机配置决定，DHCP 续约时也不会反复触发主机名更新。
证据二：SSH 断开后，systemd 清理用户进程
异常日志
Oct 05 20:45:03 localhost sshd-session[1196]: Read error from remote host 192.168.31.44 port 54349: Connection timed out
Oct 05 20:45:03 localhost sshd-session[1157]: pam_unix(sshd:session): session closed for user jiacai
Oct 05 20:45:03 localhost systemd-logind[737]: Session 2 logged out. Waiting for processes to exit.
分析
最后一行的 Waiting for processes to exit. 表明 SSH 会话已经结束。
现代 Linux 发行版通常启用了 KillUserProcesses=yes 安全机制。当网络闪断或客户端超时导致 SSH 会话断开时，systemd 会判定该用户已注销，并清理该用户 slice 中的后台进程，包括 tmux 的核心服务器。
这可以解释为什么网络波动后重新登录，tmux 中运行的服务也会消失。
解决方法
为核心用户启用 linger，避免 systemd 在 SSH 断开后清理该用户的进程：
sudo loginctl enable-linger jiacai
执行后，systemd-logind 会持续保留 jiacai 用户的 slice，为用户级服务和会话提供持续运行的用户管理器。
启用 linger 的原理是让该用户的 systemd 用户管理器不依赖当前 SSH 会话，并在系统启动时就可以运行用户级服务。需要注意的是，linger 本身不一定能阻止 KillUserProcesses=yes 清理所有直接从 SSH 会话启动的进程；要长期运行服务，更适合将它们作为用户级 systemd service 管理，或另外调整 KillUserProcesses 配置。
证据三：空闲时发生硬件重置
异常日志
Oct 06 00:34:29 localhost systemd[1]: Started cups.service - CUPS Scheduler.
Oct 06 00:34:29 localhost systemd[1]: logrotate.service: Deactivated successfully.
Oct 06 00:44:54 localhost NetworkManager[782]: <info> dhcp6 (wlp0s20f3): state changed...
Oct 06 00:45:04 loca... (后面是一片死寂的物理空白，直接跳到了几个小时后手动开机的日志)
分析
日志在 localhost 这个单词录入到一半时中断，之后没有留下 Kernel Panic 信息。这更像是物理掉电或硬件重置（Hard Reset），因为内核可能没有机会继续写入日志。
i5-8500 是台式机 CPU，支持较深的 C-States（电源休眠状态）；无线网卡也可能使用 PCIe ASPM 节能。服务器空闲、负载降到 0.00 时，Linux 6.12 测试版内核可能会让 CPU 和总线进入较深的休眠状态。
如果旧台式机主板的 BIOS 电压调度与新内核存在兼容性问题，瞬时降压可能触发欠压保护（Under Voltage Protection），导致系统重置或卡死。
解决方法
修改 GRUB 参数，禁止 CPU 进入深层低电压休眠，并关闭 PCIe 链路节能：
编辑
/etc/default/grub，在内核启动行追加参数：GRUB_CMDLINE_LINUX_DEFAULT="quiet intel_idle.max_cstate=1 processor.max_cstate=1 pcie_aspm=off"在
/etc/NetworkManager/conf.d/default-wifi-powersave-on.conf中配置无线网卡不进入节能模式：[connection] wifi.powersave = 2执行
sudo update-grub，然后执行sudo reboot冷启动。
intel_idle.max_cstate=1 和 processor.max_cstate=1 会限制处理器可进入的最深空闲状态，减少从深度休眠状态恢复时对主板电源管理的依赖。pcie_aspm=off 会关闭 PCIe 链路的主动电源管理，避免无线网卡等 PCIe 设备在空闲时进入低功耗状态。代价是待机功耗可能上升。
wifi.powersave = 2 会关闭 NetworkManager 的无线网卡节能策略，避免网卡在空闲时主动进入省电状态。update-grub 会根据 /etc/default/grub 重新生成引导配置，重启后这些内核参数才会生效。
总结
这次排查分别涉及网络层（主机名刷新）、系统层（systemd 清理用户进程）和硬件层（C-States 电源管理）。完成调整后，这台 i5-8500 无头服务器已经连续稳定运行了几天，uptime 和 tmux 会话都保持正常，没有再次出现失联。
使用无头小主机或淘汰电脑做服务器时，如果遇到“自动关机”或“服务消失”，可以先保留事故发生前的最后一段系统日志，例如：
journalctl -b -1 -n 100
先根据日志中的进程生命周期排查问题，再决定是否修改软件配置，有助于区分 systemd 行为和底层硬件供电问题。