如何排查嵌入式设备上select调用频繁触发EINTR的来源？

select 属于可被信号中断的慢系统调用：当进程在 select 阻塞等待文件描述符就绪的过程中，收到任意已注册的信号，待信号处理函数执行完成后，select 不会自动重启执行，直接返回 -1 并将 errno 设置为 EINTR

嵌入式环境频繁触发该错误、通用Linux服务器无异常的差异，本质是两类环境的信号源密度、信号配置存在区别，结合设备上存在其他独立业务进程的前提，按以下步骤逐层定位：

第一步：直接抓取打断 select 的具体信号 #

这是最快的定位方式，不需要做复杂的逻辑推断：

• 优先使用 strace -e trace=signal -p <目标进程PID> 附着到你的业务进程上，等待 select 下次触发 EINTR 时，strace 会直接输出打断调用的信号详情，包括信号类型（比如 SIGALRM、SIGUSR1、SIGIO）、信号的发送进程PID、发送方用户ID，拿到发送PID后直接通过ps命令即可定位具体进程来源。
• 如果嵌入式设备上没有预装 strace，可以在程序内自定义信号探测逻辑：通过 sigaction 给所有信号注册带 SA_SIGINFO 标志的处理函数，记录收到信号的时间、信号值、来源进程ID，等下次 select 返回 EINTR 时，对照日志即可匹配到刚被触发的信号。

第二步：结合常见场景排查信号发送方 #

拿到具体的信号类型后，按照嵌入式设备的常见场景逐一排查：

• 先排查进程自身的逻辑：是否调用过 alarm()、setitimer()、timer_create() 这类创建用户态定时器的接口，这类定时器到点发送的 SIGALRM 是打断 select 的最常见诱因。
• 再排查同设备上的其他独立进程：嵌入式环境的看门狗进程、NTP时钟同步进程、系统资源监控进程，通常会定期给业务进程发送喂狗、时钟校正类的管理信号；部分业务进程如果存在PID复用，还可能误把你的进程当成自己的子进程，发送信号触发管理操作。
• 最后排查系统内核层面的信号：如果设备开启了大量异步IO事件，内核会给进程发送 SIGIO 信号打断阻塞的 select；另外电源管理、热插拔检测类的内核逻辑，也会不定期给用户态进程发送通知信号。

对应修复兜底方案 #

完成来源定位后，可以针对性做修复：

• 对照你当前的代码逻辑，仅对非EINTR的错误做了打印，完全没有对EINTR场景做重试或来源记录，相当于被动忽略了所有被信号打断的场景，这也是问题表现频繁但无法定位的核心原因。
• 如果对应的信号不属于业务必须处理的类型，在注册信号时加上 SA_RESTART 标志，让被该信号打断的 select 类慢系统调用在信号处理完成后自动重启，不再返回 EINTR。
• 如果暂时无法定位到具体信号来源，可以在 select 调用逻辑中增加重试机制：当 select 返回 -1 且 errno 为 EINTR 时，重新计算剩余超时时间，重新发起 select 调用，避免无意义的错误返回。

内容的提问来源于stack exchange，提问作者ZH.sd