对 Omnibus GitLab 安装问题进行故障排查

使用此页面了解用户在安装 Omnibus GitLab 软件包时可能遇到的常见问题。

下载包时哈希和不匹配

apt-get install 输出如下： 

E: Failed to fetch https://packages.gitlab.com/gitlab/gitlab-ce/ubuntu/pool/trusty/main/g/gitlab-ce/gitlab-ce_8.1.0-ce.0_amd64.deb  Hash Sum mismatch

请运行以下命令来解决这个问题： 

sudo rm -rf /var/lib/apt/lists/partial/*
sudo apt-get update
sudo apt-get clean

在 openSUSE 和 SLES 平台上安装会警告未知密钥签名

除了提供签名元数据的包存储库之外，Omnibus GitLab 包使用 GPG 密钥签名。这确保了分发给用户的包的真实性和完整性。 但是，openSUSE 和 SLES 操作系统中使用的包管理器有时可能会使用这些签名引发错误警告，类似于： 

File 'repomd.xml' from repository 'gitlab_gitlab-ce' is signed with an unknown key '14219A96E15E78F4'. Continue? [yes/no] (no):
File 'repomd.xml' from repository 'gitlab_gitlab-ce' is signed with an unknown key '14219A96E15E78F4'. Continue? [yes/no] (no): yes

这是 zypper 的一个已知错误，其中 zypper 忽略仓库配置文件中的 gpgkey 关键字。在 Packagecloud 的更高版本中，可能会对此有所改进，但目前用户必须手动同意软件包安装。

所以，在 openSUSE 或 SLES 系统中，如果出现这样的警告，继续安装是安全的。

重新配置时显示错误：NoMethodError - undefined method '[]=' for nil:NilClass

您运行了 sudo gitlab-ctl reconfigure 或包升级触发了重新配置，它产生了类似于以下内容的错误： 

 ================================================================================
 Recipe Compile Error in /opt/gitlab/embedded/cookbooks/cache/cookbooks/gitlab/recipes/default.rb
 ================================================================================

NoMethodError
-------------
undefined method '[]=' for nil:NilClass

Cookbook Trace:
---------------
  /opt/gitlab/embedded/cookbooks/cache/cookbooks/gitlab/recipes/config.rb:21:in 'from_file'
  /opt/gitlab/embedded/cookbooks/cache/cookbooks/gitlab/recipes/default.rb:26:in 'from_file'

Relevant File Content:

当 /etc/gitlab/gitlab.rb 配置文件包含无效或不受支持的配置时，会显示此错误。仔细检查没有错别字或配置文件不包含过时的配置。

您可以使用 sudo gitlab-ctl diff-config 或检查最新的 gitlab.rb.template。

极狐GitLab 在我的浏览器中无法访问

尝试在 /etc/gitlab/gitlab.rb 中指定一个 external_url。还要检查您的防火墙设置；您的 GitLab 服务器上的端口 80 (HTTP) 或 443 (HTTPS) 可能已关闭。

请注意，为 GitLab 或任何其他捆绑服务（Registry 和 Mattermost）指定 external_url 不遵循 gitlab.rb 的其它部分遵循的 key=value 格式。确保按以下格式设置它们： 

external_url "https://gitlab.example.com"
registry_external_url "https://registry.example.com"
mattermost_external_url "https://mattermost.example.com"
note不要在 external_url 和值之间添加等号 (=)。

电子邮件未送达

要测试电子邮件传递，您可以为尚未在您的 GitLab 实例中使用的电子邮件创建一个新的 GitLab 帐户。

如有必要，您可以使用 /etc/gitlab/gitlab.rb 中的以下设置修改 GitLab 发送的电子邮件的 From 字段： 

gitlab_rails['gitlab_email_from'] = 'gitlab@example.com'

运行 sudo gitlab-ctl reconfigure 以使更改生效。

GitLab 服务的 TCP 端口已经被占用

默认情况下，Puma 侦听 TCP 地址 127.0.0.1:8080。NGINX 在所有接口上侦听端口 80 (HTTP) 和/或 443 (HTTPS)。

Redis、PostgreSQL 和 Puma 的端口可以在 /etc/gitlab/gitlab.rb 中被覆盖，如下： 

redis['port'] = 1234
postgresql['port'] = 2345
puma['port'] = 3456

对于 NGINX 端口更改，请参阅设置 NGINX 监听端口文档。

Git 用户没有 SSH 访问权限

支持 SELinux 的系统

在支持 SELinux 的系统上，Git 用户的 .ssh 目录或其内容可能会弄乱他们的安全上下文。您可以通过运行 sudo gitlab-ctl reconfigure 来解决这个问题，将在 /var/opt/gitlab/.ssh 上设置 gitlab_shell_t 安全上下文。

通过使用 semanage 永久设置上下文来改进此行为。运行时依赖项 policycoreutils-python 已添加到基于 RHEL 的操作系统的 RPM 包中，以确保 semanage 命令可用。

诊断并解决 SELinux 问题

Omnibus GitLab 检测到 /etc/gitlab/gitlab.rb 中的默认路径更改，并应用正确的文件上下文。对于使用自定义数据路径配置的安装，管理员可能需要手动解决 SELinux 问题。

数据路径可以通过 gitlab.rb 更改，但是，一个常见的场景会强制使用 symlink 路径。管理员应谨慎，因为并非所有场景都支持 symlink 路径，例如 Gitaly 数据路径。

例如，如果 /data/gitlab 替换 /var/opt/gitlab 作为基本数据目录，则参考以下命令修复安全上下文： 

sudo semanage fcontext -a -t gitlab_shell_t /data/gitlab/.ssh/
sudo semanage fcontext -a -t gitlab_shell_t /data/gitlab/.ssh/authorized_keys
sudo restorecon -Rv /data/gitlab/
sudo semanage fcontext -a -t gitlab_shell_t /data/gitlab/gitlab-shell/config.yml
sudo restorecon -Rv /data/gitlab/gitlab-shell/
sudo semanage fcontext -a -t gitlab_shell_t /data/gitlab/gitlab-rails/etc/gitlab_shell_secret
sudo restorecon -Rv /data/gitlab/gitlab-rails/
sudo semanage fcontext --list | grep /data/gitlab/

应用策略后，您可以通过收到欢迎消息来验证 SSH 访问是否正常： 

ssh -T git@gitlab-hostname

所有系统

默认情况下，Git 用户使用锁定的密码创建，在 /etc/shadow 中显示为 '!'。 除非启用 “UsePam yes”，否则 OpenSSH 守护程序将阻止 Git 用户使用 SSH 密钥进行身份验证。另一种安全解决方案是通过在 /etc/shadow 中用 '*' 替换 '!' 来解锁密码。Git 用户仍然无法更改密码，因为它在受限的 shell 中运行，并且非超级用户的 passwd 命令需要在输入新密码之前输入当前密码。用户无法输入与 '*' 匹配的密码，因此账号保持无密码。

请记住，Git 用户必须有权访问系统，因此请检查您在 /etc/security/access.conf 中的安全设置，并确保 Git 用户未被阻止。

PostgreSQL 错误 FATAL: could not create shared memory segment: Cannot allocate memory

打包后的 PostgreSQL 实例会尝试分配总内存的 25% 作为共享内存。在某些 Linux（虚拟）服务器上，可用的共享内存较少，这将阻止 PostgreSQL 启动。 在/var/log/gitlab/postgresql/current 中： 

  1885  2014-08-08_16:28:43.71000 FATAL:  could not create shared memory segment: Cannot allocate memory
  1886  2014-08-08_16:28:43.71002 DETAIL:  Failed system call was shmget(key=5432001, size=1126563840, 03600).
  1887  2014-08-08_16:28:43.71003 HINT:  This error usually means that PostgreSQL's request for a shared memory segment exceeded available memory or swap space, or exceeded your kernel's SHMALL parameter.  You can either reduce the request size or reconfigure the kernel with larger SHMALL.  To reduce the request size (currently 1126563840 bytes), reduce PostgreSQL's shared memory usage, perhaps by reducing shared_buffers or max_connections.
  1888  2014-08-08_16:28:43.71004       The PostgreSQL documentation contains more information about shared memory configuration.

您可以手动降低 PostgreSQL 尝试在 /etc/gitlab/gitlab.rb 中分配的共享内存量： 

postgresql['shared_buffers'] = "100MB"

运行 sudo gitlab-ctl reconfigure 以使更改生效。

PostgreSQL 错误 FATAL: could not open shared memory segment "/PostgreSQL.XXXXXXXXXX": Permission denied

默认情况下，PostgreSQL 将尝试检测要使用的共享内存类型。如果没有启用共享内存，您可能会在 /var/log/gitlab/postgresql/current 中看到这个错误。 要解决此问题，您可以禁用 PostgreSQL 的共享内存检测。在/etc/gitlab/gitlab.rb 中设置以下值： 

postgresql['dynamic_shared_memory_type'] = 'none'

运行 sudo gitlab-ctl reconfigure 以使更改生效。

重新配置时的 GLIBC 版本问题 

$ gitlab-ctl reconfigure

/opt/gitlab/embedded/bin/ruby: /lib64/libc.so.6: version `GLIBC_2.14' not found (required by /opt/gitlab/embedded/lib/libruby.so.2.1)
/opt/gitlab/embedded/bin/ruby: /lib64/libc.so.6: version `GLIBC_2.17' not found (required by /opt/gitlab/embedded/lib/libruby.so.2.1)

如果您安装的 omnibus 软件包是为与服务器上的操作系统版本不同的操作系统版本构建的，则可能会发生这种情况。 仔细检查您是否为您的操作系统下载并安装了正确的 Omnibus GitLab 软件包。

重新配置无法创建 Git 用户

如果您以 Git 用户身份运行 sudo gitlab-ctl reconfigure，就会发生这种情况。切换到另一个用户。

更重要的是：不要向 Git 用户或 Omnibus GitLab 使用的任何其它用户授予 sudo 权限。授予系统用户不必要的权限会削弱系统的安全性。

使用 sysctl 修改内核参数失败

如果 sysctl 无法修改内核参数，您可能会收到以下堆栈跟踪错误： 

 * execute[sysctl] action run
================================================================================
Error executing action `run` on resource 'execute[sysctl]'
================================================================================


Mixlib::ShellOut::ShellCommandFailed
------------------------------------
Expected process to exit with [0], but received '255'
---- Begin output of /sbin/sysctl -p /etc/sysctl.conf ----

这在非虚拟机上不太可能发生，但在像 openVZ 这样具有虚拟化功能的 VPS 上，容器可能没有启用所需的模块或容器无法访问内核参数。

尝试启用 sysctl 出错的模块。

此错误的另一个变体中，报告文件系统是只读的，并显示以下堆栈跟踪： 

 * execute[load sysctl conf] action run
    [execute] sysctl: setting key "kernel.shmall": Read-only file system
              sysctl: setting key "kernel.shmmax": Read-only file system

    ================================================================================
    Error executing action `run` on resource 'execute[load sysctl conf]'
    ================================================================================

    Mixlib::ShellOut::ShellCommandFailed
    ------------------------------------
    Expected process to exit with [0], but received '255'
    ---- Begin output of cat /etc/sysctl.conf /etc/sysctl.d/*.conf  | sysctl -e -p - ----
    STDOUT:
    STDERR: sysctl: setting key "kernel.shmall": Read-only file system
    sysctl: setting key "kernel.shmmax": Read-only file system
    ---- End output of cat /etc/sysctl.conf /etc/sysctl.d/*.conf  | sysctl -e -p - ----
    Ran cat /etc/sysctl.conf /etc/sysctl.d/*.conf  | sysctl -e -p - returned 255

此错误仅在虚拟机中报告发生，建议的解决方法是在主机中设置值。GitLab 所需的值可以在虚拟机的 /opt/gitlab/embedded/etc/90-omnibus-gitlab.conf 文件中找到。在主机操作系统的 /etc/sysctl.conf 文件中设置这些值后，在主机上运行 cat /etc/sysctl.conf /etc/sysctl.d/*.conf | sysctl -e -p -。然后尝试在虚拟机中运行 gitlab-ctl reconfigure。这样应该检测到内核已经在使用必要的设置运行，并且不会引发任何错误。

另请注意，您可能需要对其它几行重复此过程，例如重新配置将失败 3 次，您最终将在/etc/sysctl.conf 中添加如下内容： 

kernel.shmall = 4194304
kernel.sem = 250 32000 32 262
net.core.somaxconn = 1024
kernel.shmmax = 17179869184

您可能会发现查看 Chef 输出中的行比查找文件更容易（因为每个错误的文件都不同）。请参阅此代码段的最后一行。 

* file[create /opt/gitlab/embedded/etc/90-omnibus-gitlab-kernel.shmall.conf kernel.shmall] action create
  - create new file /opt/gitlab/embedded/etc/90-omnibus-gitlab-kernel.shmall.conf
  - update content in file /opt/gitlab/embedded/etc/90-omnibus-gitlab-kernel.shmall.conf from none to 6d765d
  --- /opt/gitlab/embedded/etc/90-omnibus-gitlab-kernel.shmall.conf 2017-11-28 19:09:46.864364952 +0000
  +++ /opt/gitlab/embedded/etc/.chef-90-omnibus-gitlab-kernel.shmall.conf kernel.shmall20171128-13622-sduqoj 2017-11-28 19:09:46.864364952 +0000
  @@ -1 +1,2 @@
  +kernel.shmall = 4194304

我无法在没有 root 访问权限的情况下安装 Omnibus GitLab

有时人们会问他们是否可以在没有 root 访问权限的情况下安装 GitLab。这样做有一些问题。

安装 .deb 或 .rpm

据我们所知，没有一种干净的方法可以以非特权用户身份安装 Debian 或 RPM 软件包。您不能安装 Omnibus GitLab RPM，因为 Omnibus 构建过程不会创建源 RPM。

在端口 80 和 443 上轻松托管

部署 GitLab 最常见的方法是让 Web 服务器（NGINX/Apache）与 GitLab 运行在同一台服务器上，Web 服务器侦听特权 TCP 端口（低于 1024）。在 Omnibus GitLab 中，我们通过捆绑一个自动配置的 NGINX 服务来提供这种便利，该服务需要以 root 身份运行其主进程以打开端口 80 和 443。

如果这是有问题的，安装 GitLab 的管理员可以禁用捆绑的 NGINX 服务，但这给他们带来了在应用程序更新期间保持 NGINX 配置与 GitLab 一致的负担。

Omnibus 服务之间的隔离

Omnibus GitLab 中的捆绑服务（GitLab 本身、NGINX、PostgreSQL、Redis、Mattermost）使用 Unix 用户账号相互隔离。创建和管理这些用户账号需要 root 访问权限。默认情况下，Omnibus GitLab 将在 gitlab-ctl reconfigure 期间创建所需的 Unix 帐户，但该行为可以禁用。

原则上，如果我们为每个应用程序提供自己的 runit (runsvdir)、PostgreSQL 和 Redis 进程，Omnibus GitLab 只能使用 2 个用户账号（一个用于 GitLab，一个用于 Mattermost）。 但这将是 gitlab-ctl reconfigure Chef 代码的一个重大变化，它可能会给所有现有的 Omnibus GitLab 安装带来重大的升级痛苦。（我们可能需要重新排列 /var/opt/gitlab 下的目录结构。）

调整操作系统以获得更好的性能

在 gitlab-ctl reconfigure 期间，我们设置并安装了几个 sysctl 调整以提高 PostgreSQL 性能并增加连接限制。这只能通过 root 访问来完成。

gitlab-rake assets:precompile 失败并显示 ‘Permission denied’

一些用户报告说，运行 gitlab-rake assets:precompile 不适用于 Omnibus 包。对此的简短回答是：不要运行该命令。

GitLab Web 界面使用 CSS 和 JavaScript 文件，在 Ruby on Rails-speak 中称为 “assets”。在在上游 GitLab 存储库中，这些文件以开发人员友好的方式存储：易于阅读和编辑。当您是 GitLab 的普通用户时，您不希望这些文件采用开发人员友好的格式，因为这会使 GitLab 变慢。这就是为什么 GitLab 设置过程的一部分是将 asset是 从开发人员友好的格式转换为最终用户友好的（紧凑、快速）格式； 这就是 rake assets:precompile 脚本的用途。

当我们构建 Omnibus 安装包时，我们为您编译 assets。当您使用 Omnibus 安装包安装 GitLab 时，转换后的 assets 已经存在！这就是为什么从包安装 GitLab 时不需要运行 rake assets:precompile 的原因。

当 gitlab-rake assets:precompile 因权限错误而失败时，从安全角度来看，它失败是有充分理由的：assets 无法轻易重写的事实使攻击者更难使用您的 GitLab 服务器，来提供恶意的 JavaScript 代码给您的 GitLab 服务器的访问者。

如果您想使用自定义 JavaScript 或 CSS 代码运行 GitLab，您最好从源代码运行 GitLab，或者构建自己的包。

如果您真的知道您在做什么，您可以像这样执行 gitlab-rake gitlab:assets:compile： 

sudo NO_PRIVILEGE_DROP=true USE_DB=false gitlab-rake gitlab:assets:clean gitlab:assets:compile
# user and path might be different if you changed the defaults of
# user['username'], user['group'] and gitlab_rails['dir'] in gitlab.rb
sudo chown -R git:git /var/opt/gitlab/gitlab-rails/tmp/cache

Apt 错误 ‘The requested URL returned error: 403’

尝试使用 apt 仓库安装极狐GitLab 时，如果您收到类似于以下内容的错误： 

W: Failed to fetch https://packages.gitlab.com/gitlab/gitlab-ce/DISTRO/dists/CODENAME/main/source/Sources  The requested URL returned error: 403

检查您的服务器前面是否有仓库缓存器，例如 apt-cacher-ng。

将以下行添加到 apt-cacher-ng 配置（例如在/etc/apt-cacher-ng/acng.conf中）： 

PassThroughPattern: (packages\.gitlab\.com|packages-gitlab-com\.s3\.amazonaws\.com|*\.cloudfront\.net)

在 packagecloud 博客上，阅读更多关于 apt-cacher-ng 以及需要进行此更改的原因。

使用自签名证书或自定义证书颁发机构

如果您在具有自定义证书颁发机构或使用自签名证书的隔离网络中安装 GitLab，请确保 GitLab 可以访问该证书。 不这样做会导致如下错误： 

Faraday::SSLError (SSL_connect returned=1 errno=0 state=SSLv3 read server certificate B: certificate verify failed)

当 GitLab 尝试连接 GitLab Shell 等内部服务时。

要修复这些错误，请参阅安装自定义公共证书 部分。

error: proxyRoundTripper: XXX failed with: “net/http: timeout awaiting response headers”

如果 GitLab Workhorse 在 1 分钟（默认）内没有收到来自 GitLab 的答复，它将提供一个 502 页面。

请求可能超时的原因有很多，也许用户正在加载一个非常大的差异或类似情形。

您可以通过在 /etc/gitlab/gitlab.rb 中设置值来增加默认超时值： 

gitlab_workhorse['proxy_headers_timeout'] = "2m0s"

保存文件并重新配置极狐GitLab 以使更改生效。

您想要的更改被拒绝

很可能您在 GitLab 前面有代理的环境中设置了 GitLab，并且默认情况下在包中设置的代理 headers 不适合您的环境。

有关如何覆盖默认 headers 的详细信息，请参阅更改 NGINX 文档的默认代理 headers 部分。

无法验证 CSRF 令牌已完成认证 422 Unprocessable

很可能您在 GitLab 前面有代理的环境中设置了 GitLab，并且默认情况下在包中设置的代理 headers 不适合您的环境。

有关如何覆盖默认 headers 的详细信息，请参阅更改 NGINX 文档的默认代理 headers 部分。

扩展缺少 pg_trgm

GitLab 需要 PostgreSQL 扩展 pg_trgm。如果您将 Omnibus GitLab 包与捆绑数据库一起使用，则升级时应自动启用扩展。

但是，如果您使用的是外部（非打包）数据库，则需要手动启用扩展。这样做的原因是带有外部数据库的 Omnibus GitLab 包无法确认扩展是否存在，并且它也没有启用扩展的方法。

要解决此问题，您需要先安装 pg_trgm 扩展。 该扩展位于 postgresql-contrib 包中。对于 Debian： 

sudo apt-get install postgresql-contrib

安装扩展后，以超级用户身份访问 psql 并启用扩展。

  1. 以超级用户身份访问 psql： 

    sudo gitlab-psql -d gitlabhq_production

  2. 启用扩展： 

    CREATE EXTENSION pg_trgm;
\q

  3. 现在再次运行迁移： 

    sudo gitlab-rake db:migrate

如果使用 Docker，首先需要访问你的容器，然后运行上面的命令，最后重启容器。

  1. 访问容器： 

    docker exec -it gitlab bash

  2. 运行上面的命令。

  3. 重启容器： 

    docker restart gitlab

Errno::ENOMEM: Cannot allocate memory during backup or upgrade

极狐GitLab 需要 2GB 的可用内存才能正常运行。根据服务器上其它进程的资源使用情况，安装 2GB 内存可能不够。 如果 GitLab 在不升级或运行备份时运行良好，那么添加更多 swap 应该可以解决您的问题。如果您在正常使用期间看到服务器使用 swap，则可以添加更多 RAM 以提高性能。

NGINX error: ‘could not build server_names_hash, you should increase server_names_hash_bucket_size’

如果 GitLab 的外部 URL 长于默认存储桶大小（64 字节），NGINX 可能会停止工作并在日志中显示此错误。为了允许更大的服务器名称，将 /etc/gitlab/gitlab.rb 中的存储桶大小加倍： 

nginx['server_names_hash_bucket_size'] = 128

运行 sudo gitlab-ctl reconfigure 使更改生效。

由于 NFS root_squash “’root’ cannot chown” 导致重新配置失败 

$ gitlab-ctl reconfigure

================================================================================
Error executing action `run` on resource 'ruby_block[directory resource: /gitlab-data/git-data]'
================================================================================

Errno::EPERM
------------
'root' cannot chown /gitlab-data/git-data. If using NFS mounts you will need to re-export them in 'no_root_squash' mode and try again.
Operation not permitted @ chown_internal - /gitlab-data/git-data

如果您使用 NFS 挂载了目录并在 root_squash 模式下配置，就会发生这种情况。重新配置无法正确设置目录的所有权。您需要在 NFS 服务器上的 NFS 导出中切换到使用 no_root_squash，或禁用存储目录管理并自己管理权限。

gitlab-runsvdir 未启动

适用于使用 systemd 的操作系统（例如 Ubuntu 18.04+、CentOS 等）。

gitlab-runsvdir 在 multi-user.target 而不是 basic.target 期间启动。如果您在升级 GitLab 后无法启动此服务，您可能需要通过以下命令检查您的系统是否已正确启动了 multi-user.target 所需的所有服务： 

systemctl -t target

如果一切正常，输出应如下所示： 

UNIT                   LOAD   ACTIVE SUB    DESCRIPTION
basic.target           loaded active active Basic System
cloud-config.target    loaded active active Cloud-config availability
cloud-init.target      loaded active active Cloud-init target
cryptsetup.target      loaded active active Encrypted Volumes
getty.target           loaded active active Login Prompts
graphical.target       loaded active active Graphical Interface
local-fs-pre.target    loaded active active Local File Systems (Pre)
local-fs.target        loaded active active Local File Systems
multi-user.target      loaded active active Multi-User System
network-online.target  loaded active active Network is Online
network-pre.target     loaded active active Network (Pre)
network.target         loaded active active Network
nss-user-lookup.target loaded active active User and Group Name Lookups
paths.target           loaded active active Paths
remote-fs-pre.target   loaded active active Remote File Systems (Pre)
remote-fs.target       loaded active active Remote File Systems
slices.target          loaded active active Slices
sockets.target         loaded active active Sockets
swap.target            loaded active active Swap
sysinit.target         loaded active active System Initialization
time-sync.target       loaded active active System Time Synchronized
timers.target          loaded active active Timers

LOAD   = Reflects whether the unit definition was properly loaded.
ACTIVE = The high-level unit activation state, i.e. generalization of SUB.
SUB    = The low-level unit activation state, values depend on unit type.

22 loaded units listed. Pass --all to see loaded but inactive units, too.
To show all installed unit files use 'systemctl list-unit-files'.

每一行都应该显示 loaded active active。如下行所示，如果您看到 inactive dead，这意味着可能有问题： 

multi-user.target      loaded inactive dead   start Multi-User System

要检查 systemd 可能排队的作业，请运行： 

systemctl list-jobs

如果您看到 running 作业，则服务可能会卡住，从而阻止 GitLab 启动。例如，一些用户遇到 Plymouth 无法启动的问题： 

  1 graphical.target                     start waiting
107 plymouth-quit-wait.service           start running
  2 multi-user.target                    start waiting
169 ureadahead-stop.timer                start waiting
121 gitlab-runsvdir.service              start waiting
151 system-getty.slice                   start waiting
 31 setvtrgb.service                     start waiting
122 systemd-update-utmp-runlevel.service start waiting

在这种情况下，请考虑卸载 Plymouth。

非 Docker 容器中的初始化守护进程检测

在 Docker 容器中，GitLab 包检测 /.dockerenv 文件的存在并跳过初始化系统的自动检测。但是，在非 Docker 容器（如 containerd、cri-o 等）中，该文件不存在并且包回退到 sysvinit，这可能会导致安装问题。为了防止这种情况，用户可以通过在 gitlab.rb 文件中添加以下设置来显式禁用 init 守护进程检测： 

package['detect_init'] = false

如果使用此配置，则必须在运行 gitlab-ctl reconfigure 之前启动 runit 服务，使用 runsvdir-start 命令： 

/opt/gitlab/embedded/bin/runsvdir-start &

gitlab-ctl reconfigure 在使用 AWS Cloudformation 时挂起

GitLab systemd 单元文件默认对 After 和 WantedBy 字段使用 multi-user.target。这样做是为了确保服务在 remote-fs 和 network 目标之后运行，因此 GitLab 将正常运行。

但是，这与 AWS Cloudformation 使用的 cloud-init 自己的单元排序交互不佳。

为了解决这个问题，用户可以使用 gitlab.rb 中的 package['systemd_wanted_by'] 和 package['systemd_after'] 设置来指定正确排序所需的值并运行 sudo gitlab-ctl reconfigure。重新配置完成后，重启 gitlab-runsvdir 服务以使更改生效。 

sudo systemctl restart gitlab-runsvdir

Errno::EAFNOSUPPORT: Address family not supported by protocol - socket(2)

启动 GitLab 时，如果观察到类似如下错误： ruby FATAL: Errno::EAFNOSUPPORT: Address family not supported by protocol - socket(2)

检查正在使用的主机名是否可解析并返回 IPv4 地址： 

getent hosts gitlab.example.com
# Example IPv4 output: 192.168.1.1 gitlab.example.com
# Example IPv6 output: 2002:c0a8:0101::c0a8:0101 gitlab.example.com

getent hosts localhost
# Example IPv4 output: 127.0.0.1 localhost
# Example IPv6 output: ::1 localhost

如果返回 IPv6 地址格式，请进一步检查网络接口上是否启用了 IPv6 协议支持（关键字 ipv6）： 

ip addr # or 'ifconfig' on older operating systems

当 IPv6 网络协议支持不存在或被禁用，但 DNS 配置将主机名解析为 IPv6 地址时，GitLab 服务将无法建立网络连接。

这可以通过修复 DNS 配置（或/etc/hosts）将主机解析为 IPv4 地址而不是 IPv6 来解决。

当 external_url 包含下划线时显示 URI::InvalidComponentError (bad component(expected host component: my_url.tld)

如果你使用下划线设置了 external_url（例如 https://my_company.example.com），您可能会面临以下 CI/CD 问题：

  • 将无法打开项目的 设置 > CI/CD 页面。
  • Runners 将不会选择作业，并且会失败并显示错误 500。

如果是这种情况，production.log 将包含以下错误： 

Completed 500 Internal Server Error in 50ms (ActiveRecord: 4.9ms | Elasticsearch: 0.0ms | Allocations: 17672)

URI::InvalidComponentError (bad component(expected host component): my_url.tld):

lib/api/helpers/related_resources_helpers.rb:29:in `expose_url'
ee/app/controllers/ee/projects/settings/ci_cd_controller.rb:19:in `show'
ee/lib/gitlab/ip_address_state.rb:10:in `with'
ee/app/controllers/ee/application_controller.rb:44:in `set_current_ip_address'
app/controllers/application_controller.rb:486:in `set_current_admin'
lib/gitlab/session.rb:11:in `with_session'
app/controllers/application_controller.rb:477:in `set_session_storage'
lib/gitlab/i18n.rb:73:in `with_locale'
lib/gitlab/i18n.rb:79:in `with_user_locale'

作为解决方法，请避免在 external_url 中使用下划线。

升级失败，错误 timeout: run: /opt/gitlab/service/gitaly

如果在运行重新配置时时软件包升级失败并出现以下错误，请检查所有 Gitaly 进程是否已停止，然后重新运行 sudo gitlab-ctl reconfigure。 

---- Begin output of /opt/gitlab/embedded/bin/sv restart /opt/gitlab/service/gitaly ----
STDOUT: timeout: run: /opt/gitlab/service/gitaly: (pid 4886) 15030s, got TERM
STDERR:
---- End output of /opt/gitlab/embedded/bin/sv restart /opt/gitlab/service/gitaly ----
Ran /opt/gitlab/embedded/bin/sv restart /opt/gitlab/service/gitaly returned 1