在 Arch KDE 上配置系统级 Postfix 邮件通知出口:让 root 与普通用户脚本都能简单发信

背景 在一台 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 上苹果硬件风扇控制与温度监控记录:从高温降频风险到 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 …

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 没有完整吃到 …

一次 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 相关日志中还可能出现: …

一次 OpenClaw 可见浏览器无法启动问题的排查:systemd 用户服务、KDE 图形会话与 DISPLAY 环境变量

在 Linux 桌面环境中,有些后台服务本身运行正常,却无法启动可见窗口。这个问题表面上像是浏览器坏了,或者应用自身没有正确识别图形环境;但实际原因往往更底层:服务启动时没有继承当前图形会话的环境变量。 这次遇到的问题是:OpenClaw Gateway 作为 systemd –user 用户服务运行,终端可以正常连接 Gateway,TUI 也能启动,但让它打开可见浏览器时失败,提示当前服务环境中没有 $DISPLAY 或 $WAYLAND_DISPLAY。 问题现象 在终端中启动 OpenClaw TUI 后,输入“打开浏览器”,返回类似提示: 但此时桌面环境本身是正常的,终端也处在 KDE 图形桌面中。也就是说,问题并不是“系统没有图形界面”,而是 OpenClaw Gateway 这个后台服务进程没有拿到图形会话环境。 初步确认:这是用户服务,不是系统服务 一开始容易犯的错误是直接查系统级服务: 结果会显示: 这并不代表服务不存在,而是因为 OpenClaw Gateway 安装为用户级 systemd 服务,应使用: 用户级服务文件位于类似: 这类服务由当前用户的 systemd –user 管理,而不是系统级 systemd 管理。 检查当前终端环境与服务进程环境 问题的关键在于比较两层环境: 一层是当前终端环境: 在 KDE X11 会话中,终端里通常能看到类似: 另一层是 OpenClaw …

Linux 手动维护的驱动源码应该放在哪里:从 DKMS 声卡驱动整理说起

背景 在 Linux 系统中,有些硬件驱动并不完全依赖发行版内核自带模块,而是需要额外使用第三方源码、DKMS 或手动安装脚本进行维护。常见场景包括无线网卡、特殊声卡、旧硬件驱动、笔记本专用补丁模块等。 这类源码最初往往会被临时 clone 到用户目录,例如: 这种做法在测试阶段很方便,但如果这个驱动后来成为系统长期运行所依赖的一部分,继续放在临时工作目录里就不太合适了。 一次 MacBook 声卡驱动维护过程中,就遇到了这个问题:驱动源码原本放在用户的 workspace 目录中,但该驱动实际上已经成为系统升级内核后恢复声音的重要维护组件。因此,有必要把源码移动到更合适的长期位置。 用户工作目录不适合长期保存系统驱动源码 类似下面的位置更适合作为临时工作区: 这些目录的特点是: 但如果里面存放的是长期依赖的系统驱动源码,就会出现几个问题: 尤其是 DKMS 驱动源码,它虽然最初只是一个 git 仓库,但后续可能会被反复用于: 这种性质已经不再是普通用户项目,而是本机系统维护资源。 推荐位置:/usr/local/src 对于本机管理员手动维护、非发行版包管理器安装的源码,一个比较合理的位置是: 例如: 这个位置的语义比较清楚: 它不同于发行版包管理器主要管理的 /usr/bin、/usr/lib、/usr/share 等路径,也不同于用户自己的普通文档目录。 因此,把第三方驱动的上游源码仓库放在 /usr/local/src,可以理解为: 需要区分的三个目录 以一个 DKMS 声卡驱动为例,整理后的结构可以分为三层。 1. 上游源码仓库 这是手动保留的 git 仓库,用于以后更新源码和重新安装驱动。 它的用途包括: 这个目录是人为维护的,不是 DKMS 自动生成的。 2. DKMS 注册源码目录 这是 …

Arch Linux 升级内核后 MacBook 内置声卡再次无声的排查与修复记录

问题现象 一台安装 Arch Linux 的 MacBook 在系统升级后再次出现内置扬声器无声的问题。系统中声卡设备仍然可以被识别,aplay -l 能看到 Intel HDA PCH 与 CS8409 相关设备,但实际没有声音输出。 这类问题容易被误判为 PipeWire、PulseAudio、ALSA 音量或桌面环境设置问题。但本次排查后确认,根本原因并不在用户层音频服务,而是在内核声卡驱动模块。 硬件与驱动背景 部分 MacBook 使用 Cirrus Logic CS8409 相关音频芯片,实际音频路径还涉及 CS42L83 codec。Linux 内核自带的 snd-hda-codec-cs8409 模块虽然可以识别声卡设备,但对某些 MacBook 的内置扬声器路径支持并不完整。 因此,这类机器通常需要使用 snd_hda_macbookpro 项目提供的修正版 DKMS 驱动。该驱动会覆盖或优先于内核自带的 snd-hda-codec-cs8409 模块,从而让内置声卡正常工作。 初始检查 系统升级后,首先检查当前内核版本、headers、DKMS 状态和声卡模块路径: 其中最关键的是: 如果输出类似: 说明系统正在使用内核自带的原始模块。 正确状态应该类似: updates/dkms 表示当前加载的是 DKMS …

Linux 桌面字体异常后的整理与优化记录

在 Linux 桌面环境中,字体显示异常有时并不是某一个软件本身的问题,而是系统字体目录、fontconfig 缓存、默认字体匹配顺序、位图字体配置等多个因素共同造成的。本文记录一次字体系统整理过程:在确认异常字体残留已经清除后,对本地手动安装字体进行分类整理,并清理 fontconfig 缓存,使字体系统恢复到比较干净、可维护的状态。 一、确认本地字体目录现状 首先查看 /usr/local/share/fonts 下手动安装的字体文件: 最初的目录结构比较临时化,例如: 这些目录本身并不会导致字体异常,但从长期维护角度看,可读性较差。进一步使用 fc-scan 查看字体实际识别情况: 扫描结果显示,这些字体主要包括: 也就是说,这些并不是未知字体或远程控制软件残留字体,而是手动安装的 Ubuntu、微软雅黑、Windows 中文字体、Times New Roman 和方正字体等。 二、检查位图字体配置 继续检查 fontconfig 中与 bitmap font 相关的配置: 最初只看到: 这并不是禁用位图字体,而是和位图字体缩放有关的配置。系统中同时存在 /usr/share/fonts/100dpi 和 /usr/share/fonts/75dpi 这类老式 X11 位图字体目录。现代桌面环境、浏览器、GTK、Qt、Electron 应用通常不需要它们参与字体匹配。 因此后续启用了: 启用后再次检查: 结果变为: 这表示禁用位图字体的配置已经生效,可以减少老式位图字体干扰现代桌面显示的可能性。 三、整理本地字体目录结构 为了让字体目录更自然、长期可维护,将原来的临时目录名整理成更清楚的分类目录。 创建新目录: 移动字体文件: 删除空目录: 整理后,本地字体目录结构变为: 这样的结构比单字母目录更清晰: 四、刷新 fontconfig …

Linux 桌面环境中日文字体显示异常的排查与修复记录

在 Linux 桌面环境中,中文显示正常,并不代表日文显示也一定正常。中文、日文、韩文虽然都属于 CJK 字符范围,但同一个 Unicode 汉字在不同语言环境下可能有不同的字形习惯。如果系统或网页错误地使用中文字体显示日文内容,页面虽然不会缺字,却会出现字形不协调、假名与汉字风格不统一、整体阅读感很别扭的问题。 本文记录一次日文字体显示异常的排查过程。最终确认,问题并不是系统缺少日文字体,而是由字体优先级、第三方字体残留、网页 CSS 强制指定中文字体等多个因素叠加造成。 一、问题现象 在 Arch Linux 桌面环境中,中文网页显示正常,但日文网页显示明显不自然。具体表现包括: 这种问题容易被误认为是“没有安装日语字体”,但实际情况往往更复杂。 二、先确认系统是否安装了日文字体 可以使用 fc-list 查看系统中支持日文的字体: 如果系统中已经存在类似以下字体,说明日文字体本身并不缺失: 这时问题通常不是“没有字体”,而是“系统实际选择了错误的字体”。 三、检查 fontconfig 实际匹配了什么字体 比 fc-list 更关键的是 fc-match。它可以显示当程序请求某种语言和字体族时,fontconfig 实际返回哪一个字体。 检查日语字体匹配: 异常情况下,结果可能显示为中文字体,例如: 这说明系统虽然有日文字体,但日语 sans-serif 或 serif 实际被中文字体抢走了。 理想状态应该接近: 四、清理不再需要的旧中文字体 如果系统中安装了较旧的中文字体包,例如文泉驿字体,它们可能会参与日文字符匹配。 可以先检查: 如果已经安装了这些包,并且系统中已经有 Noto CJK 或 Source Han CJK,可以考虑卸载: 卸载后刷新字体缓存: 再次检查: …

在 Linux/KDE 中把 Thunderbird 封装成托盘应用

Thunderbird 是 Linux 桌面上常用的邮件客户端。默认情况下,它启动后通常显示在任务栏中;如果关闭窗口,程序也会直接退出。对于希望长期后台收邮件、但又不想让 Thunderbird 一直占用任务栏空间的用户来说,把它封装成一个“可最小化到托盘”的应用会更符合日常使用习惯。 本文记录一种相对干净的做法:不修改 Thunderbird 本体,不改 profile,不覆盖系统自带启动器,只额外创建一个通过 KDocker 启动 Thunderbird 的 desktop 文件。 基本思路 目标不是改造 Thunderbird 本身,而是在外层加一层启动方式: 这样做的好处是: 确认 Thunderbird 的二进制路径 首先确认 Thunderbird 的实际可执行文件路径: 如果返回: 说明 Thunderbird 是系统原生安装,后续可以直接使用这个路径。 这一步很重要,因为 .desktop 文件里的 Exec= 最好写清楚实际启动的程序,而不是完全依赖环境变量搜索。 不指定 Thunderbird profile Thunderbird 的 profile 通常位于用户目录下,由 Thunderbird 自己管理。虽然可以查看 profiles.ini,但这里不建议手动指定 profile。 原因是:如果系统里有多个 profile,或者 Thunderbird …