Go语言信号驱动热重载_Golang配置文件无缝刷新-Golang-PHP中文网

go程序默认不监听sighup，需显式调用signal.notify并传入带缓冲channel（如make(chan os.signal, 1)）才能接收；linux下非session leader进程收不到sighup，windows则根本不支持该信号。

go语言信号驱动热重载_golang配置文件无缝刷新

为什么 SIGHUP 信号收不到或没反应

Go 程序默认忽略 SIGHUP，不注册处理器就完全收不到。常见现象是 consul-template 或 systemd 发了信号，但日志里毫无痕迹，配置也不变。

必须显式调用 signal.Notify 并传入带缓冲的 channel，否则信号可能丢失——尤其高频率触发时（比如连续保存两次配置）。

sigChan := make(chan os.Signal, 1) —— 缓冲大小至少为 1，不能是无缓冲 channel
监听前要确保主 goroutine 不退出，否则 signal handler 无法持续工作
别在 signal.Notify 后立刻 os.Exit 或 return，得保持 channel 活跃读取
Linux 下若用 kill -HUP <pid></pid> 测试，确认进程 PID 正确；K8s 中 ConfigMap 更新有时只发 SIGHUP，不是文件事件

收到 SIGHUP 后 reload 配置的正确姿势

信号只是通知“该 reload 了”，不代表配置已就绪。直接在 signal handler 里调 viper.ReadInConfig() 和 viper.Unmarshal() 是错的：它会阻塞信号接收循环，且没做并发保护。

标准做法是把 reload 动作转成异步任务，由独立 goroutine 执行：

收到 SIGHUP 后，只往一个 reloadChan chan struct{} 发送空结构体
另起一个 goroutine 持续 range reloadChan，每次收到就执行完整 reload 流程
reload 过程中先 os.Stat 检查文件是否存在且非空，再 viper.ReadInConfig()
解析失败时，不覆盖旧配置，只打 error 日志；成功后才用 atomic.StorePointer() 切换指针

consul-template 的 -exec 命令为什么总失败

consul-template 的 -exec 默认行为是 fork 新进程并发送 SIGHUP 给原进程，不是 kill + restart。很多人写成 -exec "sh -c 'pkill myapp && ./myapp'"，结果信号被 shell 吞掉，原进程根本收不到。

Alibabacloud Sdk Client Initialization For Golang

初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。

下载

正确写法只有两种：

直接指定二进制路径：-exec "./myapp"（适用于希望重启的场景）
或更推荐：-exec "kill -HUP $(cat /tmp/myapp.pid)"，前提是你的程序启动时写了 pid 文件
如果用 exec.Command 构建命令，注意它不会自动继承父进程 signal handler，需手动设置 syscall.Setpgid 等
本地调试时加 -disable-health-checks，避免健康检查延迟导致信号等待 30 秒才发出

Windows 下 SIGHUP 不生效的真相

Windows 本身不支持 SIGHUP，Go 在 Windows 上对 signal.Notify 的 SIGHUP 支持是模拟的，仅限于控制台关闭等极少数场景。你在 PowerShell 里 kill -Signal HUP 实际发的是 CTRL_BREAK_EVENT，Go runtime 不识别。

跨平台方案只能放弃 SIGHUP，改用：