Linux守护进程用SIGHUP重载配置，因其历史语义演变为标准通知信号，具备默认终止需显式捕获、干扰少、POSIX兼容、轻量等优势；响应时须在信号处理函数中仅设标志位，主循环再安全完成配置读取、原子切换与资源清理。
Linux守护进程收到SIGHUP后重新加载配置，核心在于进程主动捕获该信号并触发配置解析逻辑，而非内核自动重载——SIGHUP本身不携带配置信息，一切依赖进程自身的信号处理实现。
为什么用SIGHUP而不是其他信号
SIGHUP（Signal Hang Up）历史语义是“终端断开”，早期守护进程脱离终端后，父进程（如shell）退出会向子进程组发送SIGHUP。久而久之，它被约定为“通知进程重读配置”的标准信号，具备以下特点：
- 默认行为是终止进程，必须显式捕获，避免误杀
- 不被大多数系统工具随意发送，干扰少
- POSIX标准支持，跨发行版兼容性好
- 无需额外参数或IPC机制，轻量简洁
守护进程如何响应SIGHUP
关键在信号处理函数中完成三件事：安全读取新配置、原子切换、清理旧资源。典型流程如下：
- 注册sigaction()处理SIGHUP，禁用中断（SA_RESTART），避免系统调用被中断
- 在信号处理函数中仅设置标志位（如volatile sig_atomic_t reload_flag = 1），不直接解析文件（信号上下文不宜做I/O或内存分配）
- 主循环定期检查该标志，若为真，则关闭旧监听套接字、重新读取配置文件、验证语法、重建数据结构、启动新服务端口，最后重置标志
- 部分服务（如nginx）会先fork子进程加载配置，成功后再优雅切换，父进程继续服务，失败则回滚
常见陷阱与注意事项
看似简单，实操中易出问题：
- 信号丢失：连续多次SIGHUP可能被合并（尤其使用signal()而非sigaction()时），应使用sigwaitinfo()或自旋检测标志
- 配置语法错误：加载失败不能直接退出，需保留旧配置继续运行，并记录错误日志
- 资源竞争：多线程环境下，信号只发给某个线程，需统一绑定到主线程，或用pthread_sigmask()屏蔽后集中处理
- 文件权限与路径：守护进程通常以非root用户运行，确保配置文件可读；相对路径会以进程启动时的工作目录为准，建议用绝对路径
验证与调试方法
确认重载是否生效，可结合以下方式：
- 用kill -HUP $(pidof your-daemon)发送信号，观察日志中是否出现“reloading config”类提示
- 用strace -p PID -e trace=signaldeliver,openat,read跟踪信号接收及后续文件操作
- 修改配置后，检查进程打开的文件描述符（lsof -p PID）是否更新了配置文件句柄（部分服务会重新open）
- 对网络服务，可对比ss -tlnp | grep your-port中监听地址/端口是否有变化
