Linux信号机制本质是内核向进程发送的异步软中断，用于通知事件发生；常见信号如SIGINT（2）、SIGKILL（9）、SIGTERM（15）、SIGSTOP（19）等，分别对应中断、强制终止、优雅退出、暂停执行等行为，支持默认处理、忽略或自定义捕获三种响应方式。
用 strace 实时跟踪进程的信号收发
strace 是最直接的方式，能明确看到进程收到什么信号、何时收到、是否被处理或忽略。
- 监控单个进程（已知 PID）：strace -p PID -e trace=signal -f 2>&1 | grep -E "sig|SIG"
- 过滤只看 SIGTERM 和 SIGHUP：strace -p 1234 -e trace=signal 2>&1 | grep -E "(SIGTERM|SIGHUP)"
- 加时间戳便于分析频率：strace -p 1234 -e trace=signal -tt 2>&1（输出带微秒级时间）
注意：strace 会暂停目标进程，生产环境慎用；建议短时运行（如 30 秒），或对测试进程使用。
用 auditd 持续审计 kill 系统调用
auditd 可记录所有用户态发起的 kill()、tkill()、tgsi() 等系统调用，适合长期、低开销监控“谁在发信号”。
- 添加规则（记录所有 kill 调用）：auditctl -a always,exit -F arch=b64 -S kill -k signal_audit（x86_64）
- 查最近 10 条 kill 行为：ausearch -k signal_audit | tail -10
- 典型输出含：发出信号的 UID、PID、目标 PID、信号编号（例如 sig=15）、命令行（exe="/usr/bin/kill"）
该方式不影响目标进程运行，适合排查后台脚本、定时任务、监控工具误发信号等问题。
Zynq Linux Hardware Debug
下载
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
检查 /proc/PID/status 中的信号待处理状态
Linux 内核在 /proc/[PID]/status 的 SigQ 字段中暴露了进程当前待处理（pending）的实时信号数量，配合定时采样可发现“信号堆积”现象。
- 查看某进程信号队列：grep SigQ /proc/1234/status → 输出类似 SigQ: 128/127984（已排队128个，上限127984）
- 写简短脚本每秒采集一次：while sleep 1; do echo "$(date +%T) $(grep SigQ /proc/1234/status)"; done >> sigq.log
若 SigQ 第一个数字持续增长，说明进程来不及处理信号（如 handler 阻塞或过于耗时），是典型的信号风暴表现。
结合日志与应用层埋点（推荐用于服务进程）
很多守护进程（如 nginx、redis、自研服务）会在收到 SIGHUP/SIGUSR2 时主动打印 reload 日志；若发现这类日志高频出现，就说明对应信号被频繁发送。
- 实时追踪 reload 行为：journalctl -u nginx -f | grep -i "reloading\|sighup"
- 统一收集信号相关关键词：grep -E "(signal|kill|stop|start|reload)" /var/log/syslog | tail -50
对自研程序，可在 signal handler 中加入 syslog(LOG_INFO, "Received SIGUSR1 at %s", ctime(&t))，让信号行为可审计、可追溯。
