sighup成为守护进程重载配置标准信号，因其默认终止需显式捕获、守护进程通常不收真实挂断信号故干扰小、posix兼容且轻量；响应时仅在信号处理函数设标志位，主循环再安全完成配置加载与切换。
Linux 中用 SIGHUP 让守护进程重载配置，本质是向进程发送信号，由进程自身决定如何响应——内核不参与配置读取，只负责递送信号。
为什么选 SIGHUP 而不是其他信号
SIGHUP 成为重载配置的事实标准，不是因为它“自带 reload 功能”，而是因为：
- 默认行为是终止进程，必须显式捕获，避免误触发
- 守护进程通常脱离终端，几乎不会因真实挂断收到它，干扰极小
- POSIX 标准定义，所有主流发行版和 libc 都保证兼容
- 无需额外参数或 IPC 机制，一条 kill -HUP PID 就能完成通知
实际操作：发送信号的几种方式
只要知道进程 PID，就能发信号。常用方法包括：
-
直接 kill：
kill -HUP $(pidof dockerd)或kill -1 $(pgrep nginx) -
systemctl reload（推荐）：
sudo systemctl reload nginx—— 它底层就是调用kill -HUP，但更安全、可审计 -
hup 命令（部分系统提供）：
sudo hup $(pidof redis-server)
注意：普通用户只能对自己启动的进程发信号；修改系统服务配置后，通常需 root 权限执行。
Zynq Linux Hardware Debug
下载
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
守护进程内部怎么响应 SIGHUP
进程不能在信号处理函数里直接解析配置文件，否则容易出错。正确做法分两层：
-
信号处理函数中只做一件事：设置一个全局标志位，例如
volatile sig_atomic_t reload_flag = 1 - 主循环里检查并执行：定期轮询该标志，为真时才安全地打开配置文件、校验语法、替换监听套接字、清理旧资源
像 Nginx、Dockerd 这类成熟服务，还会在重载前 fork 子进程尝试加载新配置，成功后再切换，失败则保留原状态继续服务。
验证是否生效的关键点
别只看命令有没有报错，要确认配置真被应用了：
- 查日志：
journalctl -u nginx -n 20 --no-pager看是否有 “reloading configuration” 类提示 - 查文件句柄：
lsof -p $(pidof nginx) | grep nginx.conf，时间戳应更新 - 测行为：改个 listen 端口或加个 server_name，curl 测试是否按新规则响应
- 防坑提醒：确保配置文件路径是绝对路径，且守护进程运行用户有读取权限
