Arch

Arch Linux 上苹果硬件风扇控制与温度监控记录：从高温降频风险到 mbpfan 接管

摘要 一台运行 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 …

Desktop

Arch Linux KDE Plasma 高 DPI 缩放排查：从 SDDM 登录界面文字过小到全局缩放统一

背景 某台 Arch Linux 桌面系统使用 KDE Plasma 6，显示会话为 X11，登录管理器为 SDDM，桌面缩放设置为 150%。系统使用 Breeze 主题，光标、图标、颜色主题也都保持 Breeze 系列，以保证视觉风格一致。 问题出现在开机后的 SDDM 登录界面：登录前的界面没有按照预期进行缩放，文字显得很小，但鼠标指针又显得偏大。进入 KDE 桌面之后，应用界面和字体整体看起来正常，但经过进一步观察发现，桌面里的鼠标指针反而偏小。也就是说，问题并不是单纯的“SDDM 没有缩放”，而是登录界面、桌面会话、光标大小、字体 DPI 之间没有完全统一。 本次排查的目标是： 一、现象描述 系统设置中，KDE Plasma 桌面缩放比例为 150%。进入桌面后，大部分 Qt/KDE 应用显示正常。 但是开机后的 SDDM 登录界面出现以下现象： 最初容易误判为 SDDM 完全没有继承 KDE 的 150% 缩放。但后续检查发现，问题更细：SDDM 的底层 X11 DPI 已经是 144，也就是 150%，只是 SDDM greeter 没有完整吃到 …

Email

两台内部服务器 Postfix 发信配置整理记录：在不破坏中继功能的前提下统一身份与地址改写

背景 某内部环境中有两台 Debian 系服务器，分别承担虚拟化管理与备份服务。两台机器都不是实际的公网邮件服务器，也不直接对外投递邮件，而是作为本机系统邮件的提交端使用 Postfix。 整体结构如下： 其中： 代表真正负责对外收发和中继的邮件服务器。 两台内部主机上的 Postfix 只负责把本机系统邮件、告警邮件、root 邮件等提交给该邮件服务器。两台机器各自对应一个真实存在的邮件账户： 这两个账户在邮件系统中是独立账户，均可正常收发邮件。 原始状态 两台机器的对外发信功能已经长期正常运行，说明核心 SMTP 中继链路本身没有问题。 关键配置大致如下： 这些项目是邮件能否成功提交到外部邮件服务器的核心配置，因此整理过程中没有改动。 真正需要检查的是一些非核心但影响一致性和邮件头表现的项目： 发现的问题 检查后发现两台机器的核心中继配置一致，但 Postfix 自身身份和地址改写规则并不完全一致。 主要差异包括： 同时，系统层面的主机名解析也进行了确认： 整理后，两台机器的系统层面主机名保持简单结构： 这里的 host-a.lan、host-b.lan 只作为内部局域网身份使用，不等同于公网管理入口，也不等同于实际邮件服务器。 generic 是什么 generic 指的是 Postfix 的出站地址改写表，对应配置项是： 它不负责连接 SMTP 服务器，不负责 TLS，不负责 SASL 登录，也不负责端口配置。 它的作用是：在邮件交给外部邮件服务器之前，把本机生成的发件人地址改写成真实存在的邮箱账户。 例如： 在主机 A 上统一改写为： 在主机 B 上统一改写为： …

Arch

一次 KDE 用户级服务过早启动问题排查：OpenClaw、systemd 与 KWallet 的启动顺序

背景 在 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 相关日志中还可能出现： …