如何以root权限运行程序拦截其他进程的stdout与stderr？

当然可行！而且确实有比替换Node.js二进制文件优雅得多的方案，我给你梳理几种实用的实现思路，都能满足以root权限拦截其他程序stdout/stderr的需求：

1. 用ptrace系统调用跟踪进程输出（适合灵活定制） #

这是Linux下最底层的进程跟踪方式，需要root权限才能使用。原理是让你的程序作为“跟踪者”，attach到目标Node.js进程上，监控它的write系统调用——当进程往stdout（文件描述符1）或stderr（文件描述符2）写入数据时，你可以截获这些数据并处理。

如果你不想写C代码，也可以用Python的第三方库简化开发，比如python-ptrace。举个简单的逻辑示例：

from ptrace.debugger import PtraceDebugger

def intercept_write(debugger, process):
    # 监控write系统调用，过滤fd=1和fd=2的写入
    for event in debugger.waitSyscall():
        if event.syscall.name == 'write':
            fd = event.syscall.args[0]
            if fd in (1, 2):
                # 获取写入的数据内容
                data = process.readBytes(event.syscall.args[1], event.syscall.args[2])
                print(f"Intercepted {'stdout' if fd ==1 else 'stderr'}: {data.decode()}")
            event.syscall.cont()

# 附加到运行中的node进程（替换成你的进程ID）
debugger = PtraceDebugger()
process = debugger.addProcess(1234, False)
intercept_write(debugger, process)

注意：ptrace会让目标进程暂停执行直到你的处理完成，所以如果拦截逻辑太复杂，可能会影响目标程序的性能。

2. 命名管道+启动拦截（适合能控制程序启动的场景） #

如果可以控制Node.js的启动方式，完全不用动二进制文件，用命名管道就能轻松重定向输出：

• 第一步创建命名管道：

  mkfifo /tmp/node_io_pipe
  

• 第二步启动你的拦截程序，持续读取管道内容（比如存到日志或做实时分析）：

  ./your_interceptor_program /tmp/node_io_pipe
  

• 第三步启动Node.js时，把stdout和stderr都重定向到管道：

  node server.js >/tmp/node_io_pipe 2>&1
  

如果没办法手动启动Node.js，还可以用root权限配置auditd或者cgroup规则，自动拦截Node.js的启动事件，在进程启动时自动附加重定向逻辑——不过这个配置稍微复杂一点，需要写自定义的审计规则和处理脚本。

3. eBPF（高性能、低侵入的现代方案） #

这是目前Linux下最推荐的方案，性能开销极小，而且不需要暂停目标进程。eBPF可以在内核层面拦截write系统调用，过滤出目标进程（比如node）往fd=1/2的写入数据，然后把数据传到用户空间的程序里处理。

你可以用BCC工具链快速编写原型，比如一个简单的eBPF脚本：

#include <uapi/linux/ptrace.h>
#include <linux/fs.h>

BPF_PERF_OUTPUT(events);

struct data_t {
    u32 pid;
    char comm[16];
    char buf[256];
    u8 is_stderr;
};

TRACEPOINT_PROBE(syscalls, sys_enter_write) {
    struct data_t data = {};
    u32 fd = args->fd;
    if (fd != 1 && fd != 2) return 0;

    data.pid = bpf_get_current_pid_tgid() >> 32;
    bpf_get_current_comm(&data.comm, sizeof(data.comm));
    data.is_stderr = (fd == 2) ? 1 : 0;
    bpf_probe_read_user(&data.buf, sizeof(data.buf), args->buf);

    events.perf_submit(args, &data, sizeof(data));
    return 0;
}

然后用Python加载这个eBPF程序，接收并处理数据：

from bcc import BPF

b = BPF(src_file="intercept_write.c")
def print_event(cpu, data, size):
    event = b["events"].event(data)
    print(f"PID {event.pid} ({event.comm}): {'stderr' if event.is_stderr else 'stdout'}: {event.buf.decode()}")

b["events"].open_perf_buffer(print_event)
while True:
    b.perf_buffer_poll()

这个方案完全不干扰目标进程的正常运行，性能开销几乎可以忽略，非常适合长期监控场景。

一些注意事项 #

• 所有方案都需要root权限，因为涉及到跟踪其他进程或操作内核层面的资源；
• 如果目标进程已经在运行，ptrace和eBPF可以直接attach上去，命名管道则需要重启进程或者通过gdb等工具修改进程的文件描述符指向（比较繁琐）；
• eBPF需要Linux内核版本4.15以上，不过现在大多数发行版都满足这个要求。

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