GitLab docker 无法分叉“资源暂时不可用”

Question

我尝试在 ubuntu 服务器上运行 gitlab-ce docker 容器版本 22.04。

docker logs --follow gitlab

的日志输出结果为

execute[/opt/gitlab/bin/gitlab-ctl start alertmanager] action run
    [execute] /opt/gitlab/bin/gitlab-ctl: fork: retry: Resource temporarily unavailable

即使我通过使用

htop

监控有足够的可用内存。 Docker 退出并显示错误代码 137。我的

docker-compose.yml

文件看起来像

version: "3.7"
    gitlab:
        image: gitlab/gitlab-ce:latest
        container_name: gitlab
        restart: "no"
        ports:
            - "8929:8929"
            - "2289:22"
        hostname: "gitlab.example.com"
        environment:
            GITLAB_OMNIBUS_CONFIG: |
                external_url "https://gitlab.example.com"
                nginx['listen_port'] = 8929
                nginx['listen_https'] = false
                gitlab_rails['gitlab_shell_ssh_port'] = 2289
        volumes:
            - ./volumes/gitlab/config:/etc/gitlab
            - ./volumes/gitlab/logs:/var/log/gitlab
            - ./volumes/gitlab/data:/var/opt/gitlab
        shm_size: "256m"

我使用的是 docker 版本 20.10.16。其他图像与 docker 一起工作正常。

ulimit -a

的输出是

core file size          (blocks, -c) 0
data seg size           (kbytes, -d) unlimited
scheduling priority             (-e) 0
file size               (blocks, -f) unlimited
pending signals                 (-i) 1029348
max locked memory       (kbytes, -l) 65536
max memory size         (kbytes, -m) unlimited
open files                      (-n) 1024
pipe size            (512 bytes, -p) 8
POSIX message queues     (bytes, -q) 819200
real-time priority              (-r) 0
stack size              (kbytes, -s) 8192
cpu time               (seconds, -t) unlimited
max user processes              (-u) 62987
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited

Answer 1

我在虚拟服务器上遇到了同样的问题，它看起来非常像你的机器。

我猜问题是对可以同时运行的进程的限制。可能您的限制是 400，但您需要更多来运行您的 compose 网络。

cat /proc/user_beancounters | grep numproc

回复的格式如下：

held, maxheld, barrier, limit

如果运行此命令，您应该能够看到您非常接近超出限制（如果我的假设正确的话）。

查看此链接，他们谈论 Java，但一般问题是相同的： https://debianforum.de/forum/viewtopic.php?t=180774

Answer 2

我在 Docker 容器中运行 Puppeteer 时遇到了类似的问题，浏览器偶尔会无法启动，导致“fork failed”错误。经过一番研究，我发现将 init: true 添加到我的 docker-compose.yml 文件中可以解决此问题。以下是此更改为何有效的解释。

我将

init: true

添加到我的服务的

docker-compose.yml

中，解决了问题

Docker Compose 中的

init: true 选项指定应使用 init 系统（如 tini）作为容器内的 PID 1 进程。使用 init 系统的好处有几个：

1. 僵尸进程收割：当子进程终止时，它会成为僵尸进程，直到其父进程调用 wait() 读取其退出状态。如果父进程未能做到这一点，僵尸进程就会累积。初始化系统通过自动获取僵尸进程来提供帮助。
2. 信号处理：容器通常需要处理 SIGTERM 或 SIGINT 等信号才能正常关闭。初始化系统会正确处理这些信号并将它们转发到适当的进程。
3. 资源管理：init系统可以帮助管理和清理资源，保证容器环境保持稳定。

就我而言，分叉失败可能是由于僵尸进程积累并耗尽系统资源造成的。通过添加

init: true

，init 系统可以处理这些僵尸进程，防止资源耗尽和随后的 fork 失败。