27、高级主题：插件沙箱与进程隔离（fork+exec模式）

说实话，插件系统做到一定程度，你就会遇到一个绕不开的问题：插件崩溃了怎么办？

我之前在一个嵌入式监控项目里，就吃过这个亏。第三方插件写了个野指针，直接把主进程的地址表给踩了。整个系统瞬间挂掉，连日志都没来得及写。嗯，从那以后，我就对「插件必须和主进程同生共死」这件事深恶痛绝。

所以这一章，我们来聊聊真正的硬核方案——fork+exec 进程隔离。说白了，就是把插件扔到另一个进程里去跑，它炸了，主进程毫发无伤。

为什么需要进程隔离？

你想想看，传统的动态库加载（dlopen），插件和主进程共享同一个地址空间。好处是通信快，坏处是——一个非法访问，全家升天。

我见过最惨的一次，插件里有个死循环，直接把 CPU 干到 100%，主进程的实时任务全部超时。那叫一个欲哭无泪。

进程隔离能带来几个实实在在的好处：

• 故障隔离：插件进程崩溃，主进程收个 SIGCHLD 信号，优雅处理即可
• 资源限制：可以给插件进程设置 CPU 时间、内存上限，防止它吃光系统资源
• 权限控制：插件进程可以降权运行，比如用 nobody 用户，避免提权攻击
• 热重启：插件挂了，主进程可以 fork 一个新的替换上去，不停机

fork+exec 的基本流程

这里有个关键点：不要只 fork，要 fork+exec。

只 fork 的话，子进程会继承父进程的全部内存映像。如果插件有内存泄漏，fork 出来的子进程也带着一堆垃圾。而且，fork 之后子进程和父进程共享代码段，但数据段写时复制——这其实并不干净。

我个人的习惯是：fork 之后立即 exec，把子进程替换成一个全新的插件进程。这样地址空间干干净净，互不干扰。

来看一个典型的流程：

// 主进程侧：启动插件沙箱
pid_t spawn_plugin(const char *plugin_path, int argc, char *argv[]) {
    pid_t pid = fork();

    if (pid == -1) {
        perror("fork failed");
        return -1;
    }

    if (pid == 0) {
        // 子进程：这里是沙箱环境
        // 1. 可以在这里设置资源限制
        // 2. 可以切换用户/组
        // 3. 可以关闭不需要的文件描述符

        // 执行插件可执行文件
        execvp(plugin_path, argv);

        // 如果 exec 失败，到这里
        _exit(127);
    }

    // 父进程：记录子进程 PID，后续监控
    return pid;
}

你看，代码其实不多。但真正的坑，都在细节里。

进程间通信（IPC）怎么搞？

插件隔离成独立进程了，那主进程怎么跟它交互？总不能各玩各的吧。

常用的方案有这么几种：

方式	优点	缺点	适用场景
Unix Domain Socket	性能好，支持双向流	需要处理连接管理	高频交互、复杂协议
共享内存 + 信号量	延迟极低	同步复杂，容易死锁	大数据量传输
管道（pipe）	简单，可靠	半双工，数据量有限	简单命令/响应
消息队列	异步，解耦	有大小限制	事件通知

我个人最常用的是 Unix Domain Socket。为什么？因为它用起来就像网络 socket 一样，但走的是内核内部的管道，性能比 TCP loopback 高不少。而且，协议可以自己定义，扩展性也好。

资源限制与安全降权

插件进程跑起来之后，你不能让它为所欲为。我见过一个插件，因为 bug 疯狂申请内存，把系统 swap 都吃光了。

Linux 提供了 setrlimit 系统调用，可以在子进程里设置各种限制：

// 在 fork 之后，exec 之前调用
void setup_sandbox_limits() {
    struct rlimit rl;

    // 限制 CPU 时间：10 秒
    rl.rlim_cur = 10;
    rl.rlim_max = 10;
    setrlimit(RLIMIT_CPU, &rl);

    // 限制内存：100 MB
    rl.rlim_cur = 100 * 1024 * 1024;
    rl.rlim_max = 100 * 1024 * 1024;
    setrlimit(RLIMIT_AS, &rl);

    // 限制打开文件数：32 个
    rl.rlim_cur = 32;
    rl.rlim_max = 32;
    setrlimit(RLIMIT_NOFILE, &rl);

    // 限制子进程数：0，不允许再 fork
    rl.rlim_cur = 0;
    rl.rlim_max = 0;
    setrlimit(RLIMIT_NPROC, &rl);
}

另外，安全降权也很重要。我习惯在 exec 之前，把子进程的用户切换成一个低权限账号：

void drop_privileges() {
    // 切换到 nobody 用户
    struct passwd *pw = getpwnam("nobody");
    if (pw == NULL) {
        // 回退到预先定义好的 uid
        setuid(65534);
    } else {
        setuid(pw->pw_uid);
    }

    // 也可以设置 gid
    setgid(pw->pw_gid);

    // 清理补充组
    setgroups(0, NULL);
}

插件崩溃后的恢复策略

插件进程挂了，主进程怎么知道？

很简单，注册 SIGCHLD 信号处理函数：

void sigchld_handler(int sig) {
    int status;
    pid_t pid;

    // 用 WNOHANG 非阻塞地收尸
    while ((pid = waitpid(-1, &status, WNOHANG)) > 0) {
        if (WIFEXITED(status)) {
            printf("插件进程 %d 正常退出，退出码 %d\n",
                   pid, WEXITSTATUS(status));
        } else if (WIFSIGNALED(status)) {
            printf("插件进程 %d 被信号 %d 杀死\n",
                   pid, WTERMSIG(status));
        }

        // 在这里重新启动插件
        restart_plugin(pid);
    }
}

我曾经踩过一个坑：信号处理函数里不能调用 printf。因为 printf 不是异步信号安全的，可能会死锁。正确的做法是设置一个全局标志，在主循环里检查。

嗯，这里要特别注意。

SVG 架构图：插件沙箱进程隔离模型

实战中的避坑指南

讲几个我实际踩过的坑，希望能帮你省点时间：

• 僵尸进程：子进程退出后，父进程必须 wait。否则子进程变成僵尸，占着 PID 不释放。我建议用 SIGCHLD + waitpid 循环收割。
• 文件描述符泄漏：fork 之后，子进程继承了父进程的所有 fd。如果不关掉不需要的，插件就能访问主进程的 socket、文件。我习惯在 exec 前遍历关闭所有 fd（除了必要的 IPC 通道）。
• exec 失败处理：如果插件路径不对或者权限不足，exec 会返回 -1。这时候子进程必须 _exit，不能继续往下跑。否则就会出现两个主进程在跑的诡异情况。
• 信号屏蔽：fork 之后，子进程会继承父进程的信号屏蔽字。如果父进程屏蔽了某些信号，子进程可能收不到 SIGTERM。我建议在 exec 前重置所有信号处理为默认。

性能考量

进程隔离不是免费的午餐。每次 fork+exec 的开销比 dlopen 大得多。我测过，大概要多花 2-5 毫秒的启动时间。

但好处是：稳定性大幅提升。在我之前的项目里，用了进程隔离之后，主进程的连续运行时间从几天提升到了几个月。插件随便崩，主进程稳如老狗。

如果你对启动延迟敏感，可以考虑预创建进程池。提前 fork 好一批子进程，等插件请求来了直接 exec，省掉 fork 的时间。

嗯，这就是进程隔离的核心思路。说白了，就是用一点性能开销，换取整个系统的健壮性。值不值？我觉得很值。

---

公众号:蓝海资料掘金营，微信deep3321