trace_pipe为空或卡住是因为其为阻塞式fifo，需确保tracing_on=1、至少一个tracer或event启用，且必须有实际事件发生；直接cat读取，避免管道和tail-f。
为什么 trace_pipe 读出来是空的或卡住？
/sys/kernel/debug/tracing/trace_pipe 不是普通文件，它是个阻塞式 FIFO —— 没有 trace 事件产生时，read() 就挂起；一旦有新事件写入，立刻返回一行（哪怕只有一行）。很多人用 cat trace_pipe 后没看到输出，第一反应是“没生效”，其实只是 trace 还没触发。
- 确保 tracing 已启用：
echo 1 > /sys/kernel/debug/tracing/tracing_on - 确保至少一个 event 或 tracer 被激活，比如：
echo function > /sys/kernel/debug/tracing/current_tracer或echo 1 > /sys/kernel/debug/tracing/events/syscalls/sys_enter_openat/enable - 不要用
tail -f，它默认带缓冲且不兼容 FIFO；直接cat trace_pipe或用stdbuf -oL cat trace_pipe避免 stdout 缓冲干扰
如何安全地持续读取 trace_pipe 而不丢数据？
trace_pipe 是单消费者 FIFO：只要有一个进程在读，新事件就只发给它；如果读进程崩溃或关闭 fd，后续事件会堆积在内核 ring buffer 中，直到下个 reader 打开它 —— 但 buffer 满了就会覆盖旧数据。所以“持续读”关键不是轮询，而是保持 fd 打着、不中断。
- 用循环 +
read系统调用最稳，比如 Bash 中：while IFS= read -r line; do echo "$line"; done < /sys/kernel/debug/tracing/trace_pipe
- 别用
grep或管道链式处理（如cat trace_pipe | grep "open"），因为管道另一端死掉会导致trace_pipe写入阻塞，进而卡住整个 tracing 子系统 - 如果要过滤，把
grep放在循环体内，或用awk流式处理，确保 stdin 始终可读
trace_pipe 和 trace 文件的区别到底在哪？
trace 是快照视图，每次读都返回当前 ring buffer 全量内容（可能重复、含旧数据）；trace_pipe 是流式接口，每次读只返回自上次读以来新增的、未被消费过的事件 —— 它才是真正的“实时通道”。
-
trace适合调试时手动检查某一时段状态，但并发读多次会得到重叠结果 -
trace_pipe必须由单一进程独占读取，适合集成进监控脚本或日志采集器 - 性能上无差异，两者共享同一 ring buffer；但误用
trace做轮询（如watch -n0.1 'cat trace'）会频繁拷贝整 buffer，增加 CPU 开销
权限和路径失效的常见原因
/sys/kernel/debug 默认需要 root 权限，且 debugfs 可能未挂载或被禁用。
- 先确认 debugfs 是否已挂载：
mount | grep debugfs；若无，运行mount -t debugfs none /sys/kernel/debug - SELinux 或某些发行版（如 RHEL/CentOS 8+）可能默认禁用 kernel debugging，需检查
/proc/sys/kernel/kptr_restrict（值为 2 会隐藏符号地址，不影响事件本身，但让functiontracer 输出难读） -
trace_pipe在 tracing 关闭（tracing_on=0）后仍可打开，但读操作会永久阻塞 —— 所以务必先开 tracing，再开 pipe
实际用起来最常被忽略的一点：你得真有事件发生。开一堆 syscall enable，但脚本里没调 open() 或 read()，trace_pipe 就永远安静。它不预测，只回声。
