fastgpt-code-sandbox v4.15.0 在群晖 NAS 918上启动失败

[dludream]

例行检查

• 我已确认目前没有类似 issue
• 我已完整查看过项目 README，以及项目文档
• 我使用了自己的 key，并确认我的 key 是可正常使用的
• 我理解并愿意跟进此 issue，协助测试和提供反馈
• 我理解并认可上述内容，并理解项目维护者精力有限，不遵循规则的 issue 可能会被无视或直接关闭

你的版本

• 公有云版本
• 私有部署版本, 具体版本号:

问题描述, 日志截图，配置文件等

标题（Title）

fastgpt-code-sandbox v4.15.0 在群晖 NAS（DSM 定制内核）上启动失败：Python warm child failed: load seccomp filter: operation canceled

---

环境信息（Environment）

• 部署方式：Docker Compose（docker-compose-pgvector / pg 版本）
• 宿主机：群晖 Synology NAS DSM 918+
• CPU 架构：x86_64（Intel Celeron J3455）
• 内核版本：<请在此处填写，命令：uname -r>
• FastGPT 主程序版本：v4.15.1
• fastgpt-code-sandbox 镜像版本：v4.15.0
• 其他相关服务版本均已按 [V4.15.0 升级文档](https://doc.fastgpt.io/zh-CN/self-host/upgrading/4-15/41500) 迁移

问题描述（Description）

按照官方 V4.15.0 升级文档迁移 docker-compose_pg.yml 后，fastgpt-code-sandbox（v4.15.0）容器启动后反复打印以下警告，最终容器异常退出/无法保持运行：

2026-07-05 10:59:59 INF sandbox:server  Sandbox server starting on port 3000...
2026-07-05 10:59:59 INF sandbox:server  Sandbox server listening on port 3000
2026-07-05 11:00:00 WRN sandbox:server  Python warm child failed: load seccomp filter: operation canceled
2026-07-05 11:00:01 WRN sandbox:server  Python warm child failed: load seccomp filter: operation canceled
... (反复出现，直到容器退出)

同一台机器上，v4.14.15 版本的 fastgpt-code-sandbox 镜像可以正常启动、正常构建运行（配置文件其余部分未变）。

复现步骤（Steps to Reproduce）

1. 在群晖 DSM Docker（Container Manager）上，使用官方 V4.15.0 的 docker-compose_pg.yml（未做任何自定义修改，仅替换了密钥/密码类变量）
2. docker-compose up -d 启动全部服务
3. 观察 fastgpt-code-sandbox 容器日志

期望结果（Expected Behavior）

fastgpt-code-sandbox 容器正常启动并保持运行，健康检查通过。

实际结果（Actual Behavior）

容器持续打印 Python warm child failed: load seccomp filter: operation canceled，最终容器停止/不断重启，无法提供正常的代码执行沙箱服务。

已尝试的排查（What I've Tried）

1. 给容器添加 security_opt: [no-new-privileges:true, seccomp:unconfined]（关闭 Docker 外层 seccomp 限制）—— 无效，报错依旧
2. 给容器添加 privileged: true（完全放开容器权限）—— 无效，报错依旧
3. 将镜像版本回退到 v4.14.15（配置其余不变）—— 可以正常启动

初步原因分析（Root Cause Analysis）

在 projects/sandbox/src/sandbox/constants.ts 中，Python 沙箱通过 python-seccomp（libseccomp 的 Python 绑定）为每个预热的 Python 子进程加载 seccomp-BPF 过滤规则：

f = SyscallFilter(defaction=KILL)
# ... add_rule ...
f.load()

f.load() 默认会以 SECCOMP_FILTER_FLAG_TSYNC（线程同步）模式把过滤规则同步到进程内所有线程。当内核无法完成这种"多线程同步"时，libseccomp 会返回 ECANCELED，对应日志中的 operation canceled。

这是 v4.15 才引入的新的沙箱内部加固机制（v4.14.x 的镜像没有这个逻辑），怀疑与部分定制/精简内核（例如群晖 DSM 的定制内核分支）对 seccomp BPF TSYNC 多线程同步支持不完整或有限制有关，属于容器内部应用自身调用 seccomp 失败，而非 Docker 外层 seccomp 策略拦截（因为关闭外层 seccomp、甚至使用 privileged: true 都无法解决）。

诉求 / 建议（Ask）

1. 是否可以增加一个环境变量开关（例如 SANDBOX_DISABLE_NESTED_SECCOMP 之类），允许在这类内核不完整支持 seccomp TSYNC 的环境下，跳过这层内部 seccomp 加固，退回到仅靠模块白名单 + 资源限制的隔离方式，而不是让容器直接崩溃？
2. 或者在 f.load() 失败时做优雅降级（记录警告但继续用非 TSYNC 模式或不加载该层过滤，而不是导致 warm child 反复失败、容器最终不可用）？
3. 是否有计划在文档中补充这一已知兼容性限制，方便其他群晖/NAS 用户排查？

非常感谢 FastGPT 团队的工作，如果需要更多环境信息或协助测试，我可以补充。