Dify 在启动 api / worker 时，执行初始化迁移阶段触发了 Python 科学计算依赖，OpenBLAS 尝试创建 8 个线程，但容器里线程创建被拒绝了，所以直接 Aborted!。这个现象在 Dify 的历史 issue 里出现过，报错几乎一致：OpenBLAS blas_thread_init: pthread_create failed … Operation not permitted，随后 api/worker 退出。 

从你这段日志看，RLIMIT_NPROC 已经很大，不像是普通的“进程数上限太小”，更像是容器运行环境限制了线程相关系统调用，或者 OpenBLAS 的多线程初始化与当前 Docker / libseccomp 环境冲突。Docker 相关社区和官方镜像维护者也记录过这类 pthread_create failed: Operation not permitted 问题，常见根因是宿主机的 Docker / libseccomp 太旧，和较新的镜像基础环境不兼容。 

最直接、命中率最高的修法，是先把 OpenBLAS 限制成单线程。OpenBLAS 官方用法文档明确建议：如果应用本身已经是多线程，应该把 OpenBLAS 设为单线程，比如设置 OPENBLAS_NUM_THREADS=1；如果它是以 OpenMP 方式构建的，则应设置 OMP_NUM_THREADS。 

你可以直接改 Dify 的 docker-compose.yaml，给 api 和 worker 都加上这些环境变量：

services:
  api:
    environment:
      OPENBLAS_NUM_THREADS: 1
      OMP_NUM_THREADS: 1
      MKL_NUM_THREADS: 1
      NUMEXPR_NUM_THREADS: 1

  worker:
    environment:
      OPENBLAS_NUM_THREADS: 1
      OMP_NUM_THREADS: 1
      MKL_NUM_THREADS: 1
      NUMEXPR_NUM_THREADS: 1

如果你原来已经有 environment:，就把这 4 行追加进去，不要重复定义整个块。

改完后执行：

docker compose down
docker compose up -d
docker compose logs -f api
docker compose logs -f worker

如果你用的是老版本 docker-compose，也可以：

docker-compose down
docker-compose up -d
docker-compose logs -f api
docker-compose logs -f worker

如果这样改完就好了，说明根因基本就是 OpenBLAS 多线程初始化失败。

如果改完还是报同样的 Operation not permitted，第二步就看宿主机 Docker / libseccomp。Docker 官方镜像维护者提到，这类错误常常要通过升级宿主机的 Docker Engine、containerd、runc、libseccomp 来解决，尤其是老系统跑较新镜像时。 

你可以先查版本：

docker version
docker info
rpm -qa | grep -E 'docker|containerd|runc|libseccomp'

如果是 Ubuntu / Debian：

dpkg -l | grep -E 'docker|containerd|runc|libseccomp'

如果宿主机比较老，比如老版本 CentOS、Ubuntu 16/18、旧 Docker CE，这个概率会更高。Dify 那个旧 issue 里的复现场景就是较老的 Docker / Ubuntu 环境。 

还有一个仅用于验证的办法，是临时放宽 seccomp。Docker 官方文档说明可以通过 seccomp=unconfined 禁用默认 seccomp 配置来排查系统调用被拦截的问题。 

你可以在 api 和 worker 服务里临时加：

security_opt:
  - seccomp=unconfined

变成这样：

services:
  api:
    security_opt:
      - seccomp=unconfined
    environment:
      OPENBLAS_NUM_THREADS: 1
      OMP_NUM_THREADS: 1
      MKL_NUM_THREADS: 1
      NUMEXPR_NUM_THREADS: 1

  worker:
    security_opt:
      - seccomp=unconfined
    environment:
      OPENBLAS_NUM_THREADS: 1
      OMP_NUM_THREADS: 1
      MKL_NUM_THREADS: 1
      NUMEXPR_NUM_THREADS: 1

如果这样就能启动，基本可以确定是容器安全限制或宿主机运行时兼容性问题。不过这更适合作为排查手段，不建议长期作为最终方案。Docker 的 seccomp 文档也强调这是安全边界的一部分。 

我建议你按这个顺序处理：

先做第一步，只加线程限制变量。
不行再做第二步，临时加 seccomp=unconfined 验证。
如果验证通过，再回头升级宿主机 Docker / containerd / runc / libseccomp，最后把 seccomp=unconfined 去掉。 

你这个问题，本质上不是 Dify 的业务配置错了，而是启动时依赖库线程初始化被容器环境拦住了。最常见可落地修复就是这两条：

OPENBLAS_NUM_THREADS=1

必要时临时 seccomp=unconfined 做验证。 

把你现在的 docker-compose.yaml 里 api 和 worker 那两段贴出来，我可以直接按你的文件格式帮你改好。