bpftrace 报 failed to attach to tracepoint 错误的根本原因只有两个：用户无 cap_sys_admin 权限（sudo 不一定足够），或内核未启用 CONFIG_TRACEPOINTS=y、CONFIG_BPF_SYSCALL=y、CONFIG_BPF_JIT=y（或 CONFIG_BPF_INTERPRETER=y）三者之一。
为什么 bpftrace 报 failed to attach to tracepoint
这个错误不是 bpftrace 本身的问题，而是内核拒绝了 tracepoint 的 attach 请求。根本原因通常只有两个：当前用户没有足够权限，或者内核编译时没开启对应配置项。
普通用户默认无法 attach 到 tracepoint（哪怕只是读取），因为这属于内核调试接口，需要 cap_sys_admin 或 root 权限；而即使你用了 sudo，如果内核没打开关键选项，依然会失败——此时错误信息完全一样，容易误判。
必须检查的内核 CONFIG 选项
bpftrace 依赖 tracepoint 的 BPF 程序挂载能力，以下三个内核配置项缺一不可：-
CONFIG_TRACEPOINTS=y—— tracepoint 基础框架，几乎所有发行版都已启用 -
CONFIG_BPF_SYSCALL=y—— BPF 系统调用入口，bpftrace 的底层支撑 -
CONFIG_BPF_JIT=y（推荐）或CONFIG_BPF_INTERPRETER=y—— JIT 编译器或解释器，决定 BPF 程序能否执行
最容易被忽略的是 CONFIG_BPF_JIT：某些嵌入式或最小化内核（如部分 Alpine Linux、Debian netinst 镜像）可能只开了 CONFIG_BPF_SYSCALL，但没开 JIT 或 interpreter，导致 attach 时静默失败并报错 failed to attach to tracepoint。
验证方式：
zcat /proc/config.gz | grep -E "(TRACEPOINTS|BPF_SYSCALL|BPF_JIT|BPF_INTERPRETER)"或查看
/boot/config-$(uname -r)。
权限问题：sudo 不一定够，cap_sys_admin 才是关键
即使加了 sudo，如果系统启用了严格的安全模块（如某些 SELinux 策略、或 systemd 的 RestrictSUIDSGID=yes），仍可能丢掉 cap_sys_admin。常见现象：
- 在容器里运行 bpftrace（未加
--privileged或--cap-add=SYS_ADMIN） - 使用
sudo -u someuser切换用户后执行，cap 被丢弃 - systemd service 中未显式设置
CapabilityBoundingSet=CAP_SYS_ADMIN
快速验证是否是权限问题：
sudo capsh --print | grep sys_admin。如果没有输出，说明当前 shell 没有该 capability。
tracepoint 名称拼写与可用性检查
bpftrace 不会自动提示 tracepoint 是否真实存在。拼错名称（比如把 syscalls:sys_enter_openat 写成 syscalls:sys_enter_open）或目标 tracepoint 在当前内核中尚未导出，也会触发相同错误。
查可用 tracepoint 列表：
sudo cat /sys/kernel/debug/tracing/events/syscalls/（需先挂载 debugfs）。注意路径中的子目录名即 tracepoint category，文件名即 event name。
更稳妥的方式是用 bpftrace 自带的发现机制：
sudo bpftrace -l 'tracepoint:syscalls:*'。如果这条命令也报错，基本可锁定为内核配置或权限问题。
真正麻烦的往往是内核配置和 capability 的组合问题：你 sudo 了，cap_sys_admin 也在，但 CONFIG_BPF_INTERPRETER 是 n，这时候错误信息不会告诉你缺了解释器——它只会说 attach 失败。
