auto-cpufreq 在 Fedora 41 上与 Tuned 服务的冲突解决方案

在 Fedora 41 系统中，用户报告了一个常见问题：安装 auto-cpufreq 后，服务无法在系统重启后自动启动。这个问题主要源于 Fedora 41 默认启用了 Tuned 服务作为新的电源管理守护进程，与 auto-cpufreq 产生了冲突。

问题背景

Fedora 41 引入了一个重要变更：用 Tuned 服务替代了之前的 power-profiles-daemon 作为默认的电源配置文件管理守护进程。这一变更导致 auto-cpufreq 服务在系统启动时无法正常自动运行，尽管服务状态显示为已启用(enabled)。

根本原因分析

Tuned 是 Fedora 系统的动态系统调优守护进程，它会主动管理系统性能设置，包括 CPU 频率调节。当 Tuned 服务运行时，它会接管 CPU 频率管理，阻止 auto-cpufreq 正常工作。这种冲突表现为：

1. 系统重启后 auto-cpufreq 服务处于 inactive 状态
2. 需要手动执行 systemctl start 命令才能启动服务
3. CPU 频率调节功能无法自动生效

解决方案

目前有三种可行的解决方法：

方法一：完全移除 Tuned 服务

执行以下命令彻底移除 Tuned：

sudo dnf remove tuned

这种方法简单直接，但会永久移除 Fedora 的电源管理功能。

方法二：仅禁用 Tuned 服务

更推荐的方法是仅禁用而不移除 Tuned：

sudo systemctl disable --now tuned

这样保留了 Tuned 的安装，只是禁用了它的自动启动，未来需要时可以重新启用。

方法三：使用最新版 auto-cpufreq

开发团队已经提交了代码更新，在最新版本的 auto-cpufreq 中会自动检测并处理与 Tuned 的冲突。用户可以通过以下步骤获取最新代码：

1. 克隆最新仓库
2. 按照标准安装流程重新安装
3. 安装程序会自动处理 Tuned 服务的冲突问题

技术实现细节

在代码层面，解决方案是增加了对 Tuned 服务的检测和处理逻辑：

1. 新增函数检测 Tuned 服务状态
2. 在安装过程中自动停止 Tuned 服务
3. 在移除 auto-cpufreq 时恢复 Tuned 服务
4. 确保两个服务不会同时运行产生冲突

这种实现方式类似于之前处理 GNOME Power Profiles 冲突的机制，保持了代码的一致性和可维护性。

最佳实践建议

对于 Fedora 41 用户，建议采取以下步骤：

1. 首先尝试更新到最新版 auto-cpufreq
2. 如果问题仍然存在，临时禁用 Tuned 服务
3. 仅在必要时才考虑完全移除 Tuned
4. 监控系统电源管理效果，确保达到预期性能

对于开发者而言，这个案例提醒我们在开发系统工具时需要充分考虑不同发行版的默认服务差异，实现更健壮的冲突检测和处理机制。

总结

Fedora 41 的电源管理架构变更带来了与 auto-cpufreq 的兼容性问题，但通过简单的服务管理或软件更新即可解决。理解系统服务之间的交互关系对于解决这类冲突至关重要，也体现了 Linux 系统管理的灵活性。