Linux io_uring 创建失败报 EPERM 时怎么检查内核开关

Linux 程序在创建 io_uring 时返回 EPERM，先别急着把它归结为文件权限。最常见的分界是内核的 io_uring_disabled 策略：值为 1 时，普通进程只有加入指定组或拥有 CAP_SYS_ADMIN 才能创建新实例；值为 2 时，所有进程都不能创建新实例。若程序同时请求 IORING_SETUP_SQPOLL，还要单独检查该模式的特权要求。

排查顺序应是“确认失败点 → 读取两个内核开关 → 核对进程身份 → 再决定是否改策略”。io_uring_disabled 只阻止新建实例，不能据此断言已有 ring 一定失效。

先确认 EPERM 是创建策略还是 SQPOLL 权限

把日志定位到 io_uring_setup() 很重要。如果失败发生在创建 ring 的调用本身，再看内核开关；如果创建参数带有 IORING_SETUP_SQPOLL，则还要检查调用进程是否具备该模式要求的权限。两类 EPERM 的处理方向不同，直接把 sysctl 改成 0 可能掩盖真正的参数问题。

# 先确认内核策略和组配置，不修改任何系统设置
cat /proc/sys/kernel/io_uring_disabled
cat /proc/sys/kernel/io_uring_group

# 查看当前进程的有效 capability，CapEff 不是全零才说明存在能力位
grep '^CapEff:' /proc/self/status

# 解析系统中名为 io_uring 的组及其 GID；没有该组时会返回空
getent group io_uring

这里的 CapEff 是十六进制能力集合，不能只凭“当前用户是 root”判断所有服务场景；容器、systemd 单元和安全策略都可能改变进程实际拥有的能力。若程序没有使用 SQPOLL，而 io_uring_disabled 为 0，EPERM 就不应继续只从这两个开关寻找原因。

读取 io_uring_disabled 和 io_uring_group 的组合含义

内核文档把这两个 sysctl 定义成一组策略：io_uring_disabled 决定是否允许创建，io_uring_group 决定限制模式下哪个 GID 可以绕过普通用户限制。

io_uring_group 是数字 GID。不要只执行 id -nG 看名字就下结论，应同时查看数字组列表，并与 sysctl 的值比较：

# 查看当前用户的数字 UID/GID 以及附加组
id
id -G

# 查看内核允许组的数字 GID；-1 表示没有配置专用组
cat /proc/sys/kernel/io_uring_group

如果值为 1 且 group 为 -1，普通进程不能靠加入一个同名组解决，只能由具备 CAP_SYS_ADMIN 的进程创建，或由管理员调整组策略。调整前要确认这是主机安全基线的有意设置，而不是临时残留。

按权限边界选择修复，而不是直接放开内核开关

测试机若允许所有普通进程创建，可以在变更审批后把策略恢复为 0；生产机更稳妥的做法通常是保留限制，只给明确的服务账号配置允许组，并让服务重启后重新读取身份。任何变更都要记录旧值、新值、变更人和回滚值。

# 仅示例：变更前保存旧值，具体动作须经过主机变更授权
old_disabled=$(cat /proc/sys/kernel/io_uring_disabled)
old_group=$(cat /proc/sys/kernel/io_uring_group)
echo "old_disabled=$old_disabled old_group=$old_group"

# 示例：恢复为允许创建；不要在未审批的生产主机直接执行
sudo sysctl -w kernel.io_uring_disabled=0

# 变更后立即复读，确认写入的是目标主机而非容器内的临时命名空间
cat /proc/sys/kernel/io_uring_disabled

若采用组授权，服务启动身份必须确实拥有该 GID；只修改交互用户的组而不修改 systemd 服务身份，不会解决服务自己的 EPERM。若报错只在启用 SQPOLL 时出现，则优先比较“关闭 SQPOLL 能否创建”与 capability 变化，不要把这类问题误判成全局禁用。

为什么已有 io_uring 实例仍可能继续工作

io_uring_disabled=1 和 2 的语义是禁止创建新实例，内核文档明确说明已有实例仍可使用。因此一个长生命周期服务可能表现为“运行中请求正常，但重启后启动失败”：旧进程保留着已经创建的 ring，新进程在启动阶段再次调用 io_uring_setup() 时才遇到 EPERM。

最终复查可以按三点收口：一看失败堆栈是否确实指向创建；二看目标服务的 UID、GID 和 capability，而不是当前 shell；三看变更后日志是否从 EPERM 转为成功创建。这样既能修复启动问题，也不会为了一个权限边界误删或重启正在使用的实例。

常见问题

io_uring_disabled=1 时一定要改成 0 吗？

不一定。若服务账号可以加入配置的允许组，或服务拥有所需 capability，可以保留限制。是否改为 0 取决于主机安全基线和服务部署方式。

io_uring_group 填的是组名还是 GID？

填数字 GID。用 getent group 查询组名对应的数字，再与 sysctl 值和服务实际组列表比较。

已有 ring 能不能绕过新建限制？

已有实例可以继续使用，但这不等于新进程能创建实例。重启、扩容或 worker 新建时仍会重新触发创建权限检查。