优先用pgrep nginx获取主进程PID，因其直接读取procfs、避免grep干扰、输出纯净PID；也可用pidof sshd查所有PID，或通过服务PID文件如/var/run/nginx.pid定位。
直接用 kill -HUP <PID> 就行，但前提是进程本身实现了对 SIGHUP 的捕获和处理逻辑——内核只负责发信号，不负责读配置。
怎么找到目标进程的 PID
常用方法有：
-
pgrep nginx（适合已知进程名，返回主进程 PID） -
pidof sshd（返回所有匹配进程的 PID，注意守护进程常有多个子进程，一般要发给主进程） -
ps aux | grep 'mydaemon' | grep -v grep，再手动挑出主进程那一行的第二列数字 - 查服务专用 PID 文件，比如
cat /var/run/nginx.pid或/run/sshd.pid
发送信号的标准命令
确认 PID 后，执行：
linux-performance-analyzer
下载
Linux 性能分析与调优专家，覆盖 CPU、内存、磁盘 I/O、网络、内核参数、编译优化、容器/K8s。适用场景：系统卡顿/高负载、内存不足/OOM/Swap 高、CPU 异常/iowait 高。
-
kill -HUP 12345（最通用写法） -
kill -1 12345（SIGHUP 等于信号编号 1） -
kill -s HUP 12345（显式指定信号名，语义更清晰）
注意：普通用户只能给自己启动的进程发信号；修改系统服务（如 nginx、sshd）通常需要 root 权限，建议加 sudo。
验证是否真的重载成功
不能只看有没有报错，要交叉确认：
- 检查日志：如
journalctl -u nginx --since "1 minute ago"，找 “reloading”, “configuration loaded” 类关键词 - 跟踪文件操作：
strace -p $(pidof nginx) -e trace=openat,read 2>&1 | grep config，看是否重新打开了配置文件 - 对网络服务，用
ss -tlnp | grep :端口查监听状态是否更新（比如改了端口后新旧端口是否切换） - 配置生效后，实际发起请求测试行为是否按新配置运行（例如改了超时时间、访问控制规则）
常见失败原因
如果发了信号但没反应，先排查：
- 进程根本没实现 SIGHUP 处理（比如自己写的 daemon 忘了调用
sigaction()） - 发错了进程：向 worker 进程而非 master 进程发信号（如 nginx 要发给 master，不是 worker）
- 权限不足：非 root 用户尝试向系统级守护进程发信号
- 配置路径错误：进程用绝对路径读配置，但你改的是另一个位置的文件
- 语法错误导致加载失败，进程静默回退到旧配置——务必检查错误日志中是否有 parse error 提示
