Linux epoll_wait返回空events字段的条件及epoll事件循环问题咨询

问题1：epoll_wait返回的epoll_events结构体中events字段为空的触发条件 #

这种情况不算常见，但有几个明确的场景会导致：

• 监听的文件描述符被关闭：不管是当前进程自己关闭了fd，还是其他进程（比如子进程）关闭了这个fd，内核都会自动把它从epoll实例中移除。此时epoll_wait会返回这个fd，但对应的events字段可能是空的。不过要注意，多数情况下会伴随EPOLLHUP或EPOLLERR事件（这俩是内核强制上报的，不管你有没有注册），但在一些边缘场景下会出现纯空events的情况。
• 手动注册了空事件掩码：如果你调用epoll_ctl(EPOLL_CTL_ADD)或者EPOLL_CTL_MOD时，把events参数设为0（也就是没注册任何事件类型），那当内核触发这个fd的通知时，返回的events字段就是空的。这一般是代码误操作导致的，正常场景不会这么做。
• 旧内核版本的bug：在2.6.x早期的Linux内核中，处理eventfd、timerfd这类特殊fd时，偶尔会出现返回空events的bug。如果你的系统内核版本比较老，可以考虑升级后验证。

问题2：为监听描述符注册EPOLLIN事件后，accept出现异常的排查方向 #

既然你已经搞定了kqueue和select，那问题大概率出在epoll和这两者的行为差异上，给你几个排查重点：

• 检查事件注册的返回值：epoll和kqueue不一样，如果你对已经注册到epoll实例里的监听fd再次调用epoll_ctl(EPOLL_CTL_ADD)，会返回EEXIST错误。如果你的代码直接复用了kqueue的逻辑（kqueue允许重复注册），没处理这个错误，就会导致事件注册失败，epoll_wait根本不会触发该fd的事件，或者触发后状态异常，此时调用accept肯定会出错。建议的处理方式是：注册前先判断fd是否已在epoll实例中，或者先尝试EPOLL_CTL_MOD，如果返回ENOENT再调用EPOLL_CTL_ADD。
• 是否误用了边缘触发（EPOLLET）模式：如果你给监听socket加了EPOLLET事件，epoll只会在有新连接到来的第一次触发EPOLLIN，之后哪怕队列里还有pending连接，也不会再触发，直到有新的连接进来。如果你的代码在一次触发后只accept了一次，没循环accept直到EAGAIN，后续的连接就可能导致状态异常，甚至accept出错。另外，监听socket用边缘触发的话，一定要确保每次都处理完所有pending连接。
• 忽略了EPOLLERR/EPOLLHUP事件：epoll和select/kqueue不同，它会强制上报EPOLLERR和EPOLLHUP事件，不管你有没有注册。如果监听socket出了问题（比如被意外关闭、网络故障），epoll_wait会返回这个fd，但此时events里会有EPOLLERR或EPOLLHUP，如果你的代码只检查EPOLLIN就直接调用accept，肯定会出异常（比如accept返回-1，errno是EBADF或者ENOTCONN）。解决方法是：处理事件时先检查这两个错误事件，存在的话先处理fd的错误状态（比如关闭fd、从epoll里移除），再决定要不要调用accept。
• accept的错误处理逻辑有问题：epoll触发EPOLLIN时，不一定真的有可用连接——极端情况下，连接可能在epoll触发后、accept前被客户端关闭，此时accept会返回EAGAIN或者ECONNABORTED。如果你的代码没处理这些errno，直接当成严重异常，就会出现你遇到的情况。建议调用accept后一定要检查返回值，对EAGAIN/ECONNABORTED这类错误做重试或者忽略，别直接报错。
• 监听socket的backlog设置太小：如果listen的backlog设得太小，pending连接队列满了之后，新的连接会被内核拒绝，但epoll还是会触发EPOLLIN（因为队列里还有没处理的连接），如果你的代码accept时没处理可能的错误，也会出问题。可以先把backlog调大（比如设为1024）试试，看能不能解决。

内容的提问来源于stack exchange，提问作者Chuck Remes