关键在于厘清“谁发的、什么时候发的、为什么发”，信号只来自硬件异常、内核自动触发、其他进程发送三类源头，需结合strace、/proc/[pid]/status、审计日志等逐项排查。
排查进程收到未知信号的原因，关键在于厘清“谁发的、什么时候发的、为什么发”，而不是盲目查日志或重启。信号本身不带上下文，但它的产生路径是确定且可追溯的。
确认进程实际收到了哪个信号
很多所谓“未知信号”其实是没看清信号编号。先用基础手段锁定具体信号：
- 启动进程时加 strace -e trace=signal，实时捕获所有信号收发，例如：
strace -e trace=signal ./myserver - 进程运行中，用 kill -l 查看当前系统支持的信号列表，再结合 /proc/[pid]/status 中的 SigQ（队列中未决信号数）和 SigPnd（待处理信号掩码）辅助判断
- 若进程已崩溃，检查是否生成了 core dump；用 gdb core 加载后执行 info registers 和 bt，崩溃时的 si_signo 字段会明确显示触发信号编号
排查三类常见信号来源
信号只来自三处：硬件异常、内核自动触发、其他进程显式发送。按优先级逐项排除：
- 硬件/软件异常：SIGSEGV（11）、SIGBUS（7）、SIGFPE（8）、SIGILL（4）基本都源于代码缺陷。检查是否有非法内存访问、除零、未对齐读写、调用损坏函数指针等。用 gcc -g -O0 编译 + valgrind 或 AddressSanitizer 可快速定位
- 内核自动触发：SIGHUP（1）常因控制终端断开（如 ssh 断连、nohup 启动但父 shell 退出）；SIGPIPE（13）发生在向已关闭管道/Socket 写数据；SIGXCPU/SIGXFSZ（24/25）是资源限制超限（ulimit 设置过严），查 ulimit -a 和 /proc/[pid]/limits
- 其他进程发送：用 ps -eo pid,ppid,comm | grep [pid] 看父进程是谁；再用 auditctl -a always,exit -F arch=b64 -S kill（需 root）开启审计，记录所有 kill 系统调用的发起者、PID、信号号
检查信号是否被意外屏蔽或忽略
进程可能“收得到但看不见”——不是没收到，而是被阻塞或忽略：
- 用 cat /proc/[pid]/status | grep SigBlk 查看当前被阻塞的信号掩码（十六进制），对照 kill -l 转换为十进制信号号
- 检查代码中是否调用了 sigprocmask()、pthread_sigmask() 或在 signal() / sigaction() 中设了 SIG_IGN；特别是多线程程序，信号掩码在线程间不继承，主线程屏蔽的信号子线程未必屏蔽
- 某些守护进程（如 systemd 启动的服务）默认会重置信号处理行为，导致自定义 handler 失效，需显式调用 sigaction() 并设 SA_RESTART 等标志
复现与隔离验证
无法稳定复现的问题，要主动构造边界条件：
- 用 kill -STOP [pid] 暂停进程，再用 kill -CONT 恢复，观察是否在恢复瞬间触发信号（如某些驱动或定时器逻辑依赖调度时机）
- 在可疑代码段前后插入 raise(SIGUSR2) 打桩，配合 strace 观察执行流是否被中断，确认问题是否真由外部信号引起，而非逻辑卡死或锁竞争
- 用 unshare --user --pid --fork /bin/bash 创建最小隔离环境，排除容器、cgroup、SELinux 等外部策略干扰
