thinkfan守护进程与信号机制深度剖析：SIGHUP配置热重载、fork双次启动与PID文件防重入设计

thinkfan守护进程与信号机制深度剖析：SIGHUP配置热重载、fork双次启动与PID文件防重入设计

【免费下载链接】thinkfanThe minimalist fan control program项目地址: https://gitcode.com/gh_mirrors/th/thinkfan

thinkfan 是一款极简的 Linux 风扇控制程序，它按预设温度档位自动调节风扇转速，守护你的笔记本远离高温。本文面向新手，剖析它稳定运行在后台的三大核心机制：SIGHUP 配置热重载、fork 双次启动与 PID 文件防重入设计，帮助你看懂一个优秀守护进程的完整设计思路。

💡 全文机制均对应主程序入口src/thinkfan.cpp，无需深入 C++，只要理解“进程”和“信号”两个概念即可读懂。

全局视野：一个守护进程如何被"远程遥控"

thinkfan 启动后默认成为后台守护进程（daemon），并把自身进程号写入 PID 文件（通常位于/run/thinkfan.pid，由CMakeLists.txt在编译期确定）。从此它不再占用你的终端，管理员只需用kill命令发送不同信号，就能远程操控它：

这套"信号即接口"的设计，让 thinkfan 在不引入 socket、REST API 等复杂通信机制的前提下，拥有了完整的运维能力。所有信号逻辑集中在src/thinkfan.cpp的sig_handler()函数中，仅约 20 行。

如何一键热重载配置：SIGHUP 的三步安全机制

🔄 修改温度档位后重启整个程序，会让风扇控制出现一段空窗期。thinkfan 用 SIGHUP 实现了"无停机"热重载，分三步走：

第一步：信号处理函数只做"最轻的事"。sig_handler()收到 SIGHUP 后只设置原子标志位interrupted并唤醒睡眠条件变量（sleep_cond.notify_all()），绝不在信号处理函数里做文件读取等复杂操作——这是信号安全（signal-safe）的经典做法。

第二步：主循环醒来后重新读配置。run()返回后，main()检测到interrupted == SIGHUP，便调用Config::read_config()读取新配置，再通过config.swap()原子地替换旧配置，然后清零标志位、继续监控循环。

第三步：新配置出错时"保底"。如果新配置存在语法错误，程序会捕获异常并记录日志"Error reloading config. Keeping old one."，继续沿用旧配置运行——风扇控制永远不会因为一次误操作而中断。

实操步骤只有两条：

1. 编辑配置文件（YAML 示例见examples/thinkfan.yaml）；
2. 发送信号让改动立即生效：

kill -HUP "$(cat /run/thinkfan.pid)"

fork 双次启动：为什么 thinkfan 要"启动两次"？

⚡ 仔细看main()的流程，你会发现配置其实被完整加载了两次，这正是"双次启动"的含义：

第一次：fork 之前的"预检"。程序先完整读取配置、初始化传感器并读取一次温度。这一步在前台完成，好处是：如果配置写错了、传感器路径不存在，错误会直接打印给你看，进程退出，不会留下任何孤儿后台进程。

然后 fork 分家。

• 父进程：打印Daemon PID: xxx后立即返回 0，交还终端给你；
• 子进程：启用 syslog（日志转入系统日志而非终端），创建 PID 文件持有者并写入自己的进程号。

第二次：fork 之后的"正式上岗"。子进程再次调用Config::read_config()加载真正的配置对象，调用init()初始化后进入无限监控循环：每隔sleeptime秒（默认 5 秒）读取温度、按档位计算并写入风扇速度。

这种设计把"可能失败的准备工作"和"长期运行的守护职责"干净地分离开：预检失败 → 无副作用；预检通过 → 必然得到一个可靠的后台进程。调试时加-n参数则跳过整个 fork 流程，程序留在前台并把日志打到终端，方便新手排查问题。

PID 文件防重入：防止两个 thinkfan 互抢风扇

🛡️ 风扇只有一个控制口，如果同时运行两个 thinkfan 实例，它们会像两个人抢方向盘一样反复改写转速。thinkfan 的解法是一个极简的"锁"——PID 文件：

1. 启动前检查：main()里先调用PidFileHolder::file_exists()，文件已存在则直接报错退出，并提示"可能 thinkfan 已在运行，或被 SIGKILL 杀死后残留了文件，确认无进程后手动删除即可"（文案见src/message.h的MSG_RUNNING）；
2. 子进程写入：fork 后的子进程才创建PidFileHolder（类定义在src/thinkfan.h），把自己的进程号写入/run/thinkfan.pid；
3. 优雅退出即自动解锁：PidFileHolder的析构函数会关闭并unlink()该文件，正常退出（SIGTERM/SIGINT 或热重载切换）都能自动清理。

这套"构造上锁、析构解锁"的 RAII 写法保证了锁的生命周期与进程严格绑定。OpenRC 启动脚本（rcscripts/openrc/thinkfan.cmake）也通过pidfile声明复用同一个文件，服务管理器与 thinkfan 各取所需。

休眠与唤醒：SIGPWR 和 SIGUSR2 的优雅配合

💤 笔记本休眠时传感器会"失联"，唤醒后风扇状态又需要重建。thinkfan 用两个自定义信号信号量把这段旅程处理得非常顺滑，对应的 systemd 服务文件也随项目一起提供：

• 休眠前（rcscripts/systemd/thinkfan-sleep.service）：发送 SIGPWR，并刻意sleep 1等待信号处理完，避免与休眠时序竞争。收到信号后，thinkfan 把tolerate_errors设为 4——接下来 4 个循环内传感器读错也不报错、不退出；
• 唤醒后（rcscripts/systemd/thinkfan-wakeup.service）：发送 SIGUSR2，主循环执行config->init_fans()重新初始化风扇控制，转速立刻恢复智能调节。

核心机制小结

thinkfan 用不到几百行的守护进程代码，完整覆盖了"可运维、可自愈、防误用"三个维度——这正是它被称作"极简却不简陋"的风扇控制程序的原因。理解了这三个机制，你基本也就掌握了 Linux 守护程序设计中最通用的一套模板。

【免费下载链接】thinkfanThe minimalist fan control program项目地址: https://gitcode.com/gh_mirrors/th/thinkfan