小站

背景 在一台 Arch KDE 桌面主机上，存在一个很实际的需求：当脚本、备份任务、系统维护任务或定时任务开始执行时，发送一封通知邮件，提示“任务已经开始，请不要关机”；当任务完成或失败时，再发送一封结果邮件。 目标不是在桌面主机上搭建完整邮件服务器，也不是让它接收外部邮件，而是让它具备一个稳定、统一、简单的“系统级发信出口”。 最终希望脚本中可以直接写： 任务完成时： 任务失败时： 无论脚本由普通用户执行，还是由 root 执行，都应能用同样方式发信。 已有经验：PVE/PBS 的系统级邮件出口 在已有服务器环境中，PVE 和 PBS 已经配置过邮件通知。它们通过本机 Postfix 将系统通知中继到外部 SMTP 服务，并使用专用账号作为发件人。备份任务、系统任务完成后都能正常发送通知邮件。 这类方案的特点是： 这种结构非常适合 PVE/PBS 这类服务器系统，因为系统任务天然由 root、systemd 或 cron 执行。如果桌面主机也希望 root 任务和普通用户任务都能统一发信，那么系统级 Postfix relay/null-client 方案比用户级 SMTP 客户端更合适。 为什么没有采用用户级 msmtp 方案 最初也可以考虑 msmtp + mailx 方案。它很轻量，适合普通用户脚本发信： 但当需求扩展为“root 任务也要发信”时，用户级方案会迅速变复杂： 这样会带来几个问题： 而实际需求只是希望以后脚本里能简单调用 mailx。因此，继续扩展用户级方案并不合适。 …

摘要 一台运行 Arch Linux 的苹果硬件设备，在重任务后出现 CPU 温度接近高温上限的情况。排查发现，系统中已经加载 applesmc，并且存在 fan1_input、fan1_min、fan1_max 等 Apple SMC 风扇接口。这说明该设备的风扇控制并不适合优先使用通用 fancontrol，而更适合使用面向苹果硬件的 mbpfan。 最终处理方案是： 实施后，风扇不再长期停留在最低转速附近，而是可以随温度上升自动提高转速，温度控制状态明显改善。 一、问题背景 设备在重任务后曾出现 CPU 温度接近高温上限的情况。虽然温度随后下降，但该现象说明系统默认风扇策略可能偏保守，在 Linux 下没有及时把风扇转速拉高。 初始观察到的状态大致如下： 这种情况的风险在于： 因此，本次目标不是追求极限性能，而是让风扇更早介入，避免 CPU 在重任务下反复冲到高温边缘。 二、确认风扇控制接口 首先确认系统是否加载了苹果硬件相关模块： 如果输出中存在： 说明系统已经具备读取 Apple SMC 与 CPU 温度的基础条件。 然后确认风扇接口： 如果可以看到类似文件： 说明风扇是通过 Apple SMC 暴露出来的。 典型读数可能类似： 这些数值应以本机实际读取结果为准。 三、为什么选择 mbpfan 而不是 fancontrol fancontrol …

背景 在 Arch Linux + KDE Plasma 桌面环境中，OpenClaw Gateway 作为用户级 systemd 服务运行。为了避免在配置文件中保存明文密钥，Gateway 的认证信息通过 KDE Wallet 读取。这个设计本身是合理的：密钥交给桌面会话的钱包管理，服务启动时再通过本地 secret provider 取出。 问题出现在一次系统或应用更新之后。原本已经调整过的用户级 systemd 启动关系，被重新生成了一个 default.target.wants 下的链接，导致 OpenClaw Gateway 再次过早启动。由于启动时间早于 KDE 图形会话完全就绪，也早于 KWallet 通过 PAM 完成解锁，Gateway 无法读取钱包中的 secret，最终启动失败。 这个问题表面上像是 KWallet 崩溃、Qt 插件缺失，甚至 KDE 环境异常；但实际根因是：用户级 systemd 服务被错误地挂回了 default.target，启动顺序早于图形会话和钱包解锁。 现象 系统启动后，OpenClaw Gateway 没有稳定进入可用状态。日志中可以看到类似信息： 同时，KWallet 相关日志中还可能出现： …