正式なドキュメントは英語版であり、この日本語訳はAI支援翻訳により作成された参考用のものです。日本語訳の一部の内容は人間によるレビューがまだ行われていないため、翻訳のタイミングにより英語版との間に差異が生じることがあります。最新かつ正確な情報については、英語版をご参照ください。

Linuxパッケージのインストールに関するトラブルシューティング

  • プラン: Free、Premium、Ultimate
  • 提供形態: GitLab Self-Managed

このページでは、Linuxパッケージのインストール時にユーザーが遭遇する可能性のある一般的な問題について説明します。

パッケージのダウンロード時のハッシュ合計の不一致

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

詳細については、Packagecloud commentのJoe Damato氏と彼のブログ記事を参照してください。

別の回避策として、CEパッケージまたはEEパッケージリポジトリから正しいパッケージを手動で選択してダウンロードします:

curl -LJO "https://packages.gitlab.com/gitlab/gitlab-ce/packages/ubuntu/trusty/gitlab-ce_8.1.0-ce.0_amd64.deb/download"
dpkg -i gitlab-ce_8.1.0-ce.0_amd64.deb

openSUSEおよびSLESプラットフォームへのインストールで、不明なキー署名について警告が表示される

Linuxパッケージは、パッケージリポジトリが署名付きメタデータを提供するだけでなく、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がリポジトリ設定ファイルのgpgkeyキーワードを無視するという、zypperの既知のバグです。Packagecloudの新しいバージョンでは、これに関する改善が行われる可能性がありますが、現在、ユーザーは手動でパッケージのインストールに同意する必要があります。

したがって、openSUSEまたはSLESシステムでは、このような警告が表示された場合でも、インストールを続行しても安全です。

apt/yumがGPG署名について文句を言う

すでにGitLabリポジトリが設定されていて、apt-get update、apt-get install、またはyum installを実行し、次のようなエラーが表示された:

The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 3F01618A51312F3F

または

https://packages.gitlab.com/gitlab/gitlab-ee/el/7/x86_64/repodata/repomd.xml: [Errno -1] repomd.xml signature could not be verified for gitlab-ee

これは、2020年4月にGitLabがPackagecloudインスタンスから利用できるaptおよびyumリポジトリのメタデータへの署名に使用されるGPGキーを変更したためです。このエラーが表示された場合、通常は、キーリング内のリポジトリメタデータへの署名に現在使用されている公開キーがないことを意味します。このエラーを解決するには、新しいキーを取得する手順に従ってください。

再設定でエラーが表示される: 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にアクセスできない

指定 external_urlを/etc/gitlab/gitlab.rbで試してください。また、ファイアウォールの設定も確認してください。 GitLabサーバーでポート80 (HTTP) または443 (HTTPS) が閉じられている可能性があります。

GitLabまたはその他のバンドルされたサービス (レジストリおよびMattermost) にexternal_urlを指定しても、key=value形式には従いません。 gitlab.rbの他の部分が従います。次の形式で設定されていることを確認してください:

external_url "https://gitlab.example.com"
registry_external_url "https://registry.example.com"
mattermost_external_url "https://mattermost.example.com"

=と値の間に等号 (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ランタイムの依存関係が、semanageコマンドが利用可能であることを保証するために、RHELベースのオペレーティングシステムのRPMパッケージに追加されました。

SELinuxの問題を診断して解決する

Linuxパッケージは、/etc/gitlab/gitlab.rbのデフォルトのパスの変更を検出し、正しいファイルコンテキストを適用する必要があります。

GitLab 16.10以降、管理者はgitlab-ctl apply-sepolicyを試してSELinuxの問題を自動的に修正できます。実行時のオプションについては、gitlab-ctl apply-sepolicy --helpを参照してください。

カスタムデータパス設定を使用するインストールの場合、管理者は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デーモンは、SSHキーがあっても、Gitユーザーの認証を妨げます。別の安全な解決策は、/etc/shadowで'!'を'*'に置き換えることで、パスワードのロックを解除することです。Gitユーザーは制限付きShellで実行され、非スーパーユーザー用のpasswdコマンドは新しいパスワードの前に現在のパスワードの入力を必要とするため、パスワードを変更できません。ユーザーは'*'と一致するパスワードを入力できません。つまり、アカウントはパスワードを引き続き持っていません。

Gitユーザーはシステムにアクセスできる必要があることに注意してください。したがって、/etc/security/access.confでセキュリティ設定を確認し、Gitユーザーがブロックされていないことを確認してください。

エラー: 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.

/etc/gitlab/gitlab.rbでPostgreSQLが割り当てようとする共有メモリーの量を手動で減らすことができます:

postgresql['shared_buffers'] = "100MB"

変更を有効にするには、sudo gitlab-ctl reconfigureを実行します。

エラー: 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を実行します。

エラー: FATAL: remaining connection slots are reserved for non-replication superuser connections

PostgreSQLには、データベースサーバーへの同時接続の最大数を設定する設定があります。デフォルトの制限は400です。このエラーが表示された場合、GitLabインスタンスが同時接続数に対するこの制限を超えようとしていることを意味します。

最大接続数と利用可能な接続数を確認するには:

  1. PostgreSQLデータベースコンソールを開きます:

    sudo gitlab-psql

  2. データベースコンソールで次のクエリを実行します:

    SELECT
  (SELECT setting::int FROM pg_settings WHERE name = 'max_connections') AS max_connections,
  COUNT(*) AS current_connections,
  COUNT(*) FILTER (WHERE state = 'active') AS active_connections,
  ((SELECT setting::int FROM pg_settings WHERE name = 'max_connections') - COUNT(*)) AS remaining_connections
FROM pg_stat_activity;

この問題を解決するには、2つのオプションがあります:

  • または、最大接続の値を大きくします:

    1. /etc/gitlab/gitlab.rbを編集します:

      postgresql['max_connections'] = 600

    2. GitLabを再設定します:

      sudo gitlab-ctl reconfigure

    3. GitLabを再起動します。

      sudo gitlab-ctl restart

  • または、PostgreSQLの接続であるPgBouncerの使用を検討してください。

再設定で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)

これは、インストールしたLinuxパッケージが、サーバー上のものとは異なるOSリリース用に構築された場合に発生する可能性があります。オペレーティングシステムに適したLinuxパッケージをダウンロードしてインストールしたことを再確認してください。

再設定でGitユーザーの作成に失敗する

これは、Gitユーザーとしてsudo gitlab-ctl reconfigureを実行した場合に発生する可能性があります。別のユーザーに切り替えます。

さらに重要なことは、Linuxパッケージで使用されているGitユーザーまたはその他のユーザーにsudo権限を与えないことです。システムユーザーに不必要な特権を与えると、システムのセキュリティが低下します。

systemdによるカーネルパラメータの変更に失敗しました

systemdがカーネルパラメータを変更できない場合は、次のスタックトレースでエラーが発生する可能性があります:

 * 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では、コンテナに必要なモジュールが有効になっていないか、コンテナがカーネルパラメータにアクセスできない可能性があります。

systemdがエラーを出したモジュールを有効にするを試してください。

このイシューに記載されている回避策があり、GitLabの内部レシピを編集して、エラーを無視するスイッチを指定する必要があります。エラーを無視すると、GitLabサーバーのパフォーマンスに予期しない副次効果が発生する可能性があるため、これを行うことはお勧めしません。

このエラーの別のバリエーションでは、ファイルシステムが読み取り専用であると報告され、次のスタックトレースが表示されます:

 * 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内にあります。これらの値をホストOSの/etc/sysctl.confファイルに設定した後、ホストでcat /etc/sysctl.conf /etc/sysctl.d/*.conf | sysctl -e -p -を実行します。次に、仮想マシン内でgitlab-ctl reconfigureを実行してみてください。カーネルが必要な設定ですでに実行されていることを検出し、エラーが発生しないはずです。

他の行についてこのプロセスを繰り返す必要がある場合があります。たとえば、/etc/sysctl.confに次のようなものを追加した後、再設定が3回失敗します:

kernel.shmall = 4194304
kernel.sem = 250 32000 32 262
net.core.somaxconn = 2048
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

ルートアクセスなしでGitLabをインストールできない

時々、ルートアクセスなしでGitLabをインストールできるかどうか尋ねる人がいます。これにはいくつかの理由で問題があります。

.debまたは.rpmのインストール

私たちの知る限りでは、特権のないユーザーとしてDebianまたはRPMパッケージをインストールする簡単な方法はありません。ビルドプロセスではソースRPMが作成されないため、LinuxパッケージRPMをインストールできません。

ポート80および443での手間のかからないホスティング

GitLabをデプロイする最も一般的な方法は、Webサーバー (NGINX/Apache) をGitLabと同じサーバー上で実行し、Webサーバーが特権 (1024未満) TCPポートでリッスンするようにすることです。Linuxパッケージでは、ポート80および443を開くために、ルートとしてマスタープロセスを実行する必要がある、自動的に設定されたNGINXサービスをバンドルすることで、この利便性を提供します。

これが問題となる場合、GitLabをインストールする管理者はバンドルされたNGINXサービスを無効にすることができますが、これにより、アプリケーションの更新中にNGINX設定をGitLabと一致させる負担が発生します。

サービス間の分離

Linuxパッケージのバンドルされたサービス (GitLab自体、NGINX、PostgreSQL、Redis、Mattermost) は、Unixユーザーアカウントを使用して互いに分離されています。これらのユーザーアカウントの作成と管理には、ルートアクセスが必要です。デフォルトでは、Linuxパッケージはgitlab-ctl reconfigure中に必要なUnixアカウントを作成しますが、その動作は無効にできます。

原則として、各アプリケーションに独自のrunit (runsvdir)、PostgreSQLおよびRedisプロセスを提供する場合、Linuxパッケージは2つのユーザーアカウント (GitLab用とMattermost用) のみで実行できます。ただし、これはgitlab-ctl reconfigure Chefコードの大幅な変更となり、既存のすべてのLinuxパッケージインストールで大きなアップグレードの問題が発生する可能性があります。おそらく、/var/opt/gitlabの下のディレクトリ構造を再配置する必要があるでしょう。

パフォーマンスを向上させるためのオペレーティングシステムの微調整

gitlab-ctl reconfigure中に、PostgreSQLのパフォーマンスを向上させ、接続制限を増やすために、いくつかのsysctl微調整を設定してインストールします。これは、ルートアクセスでのみ実行できます。

gitlab-rake assets:precompileがPermission deniedで失敗する

一部のユーザーは、gitlab-rake assets:precompileの実行がLinuxパッケージでは機能しないと報告しています。これに対する簡単な答えは、そのコマンドを実行しないでください。ソースからのGitLabインストールのみを対象としています。

GitLab Webインターフェースは、Ruby on Railsで言うところの「アセット」と呼ばれるCSSファイルとJavaScriptファイルを使用します。アップストリームGitLabリポジトリでは、これらのファイルはデベロッパーにとって使いやすい方法で保存されます。読みやすく編集しやすいです。ただし、GitLabの通常のユーザーの場合、これらのファイルはデベロッパーにとって使いやすい形式にはしたくありません。GitLabの速度が低下するためです。これが、GitLabのセットアッププロセスの一部が、アセットをデベロッパーにとって使いやすい形式から、エンドユーザーにとって使いやすい (コンパクト、高速) 形式に変換することである理由です。これがrake assets:precompileスクリプトの目的です。

GitLabをソースからインストールする場合 (Linuxパッケージを入手する前の唯一の方法でした)、GitLabを更新するたびにGitLabサーバー上のアセットを変換する必要があります。人々はこの手順を見落としがちで、インターネット上にはまだ、ユーザーがrake assets:precompile (現在はgitlab:assets:compileに名前が変更されました) を実行することを互いに推奨する投稿、コメント、メールがあります。Linuxパッケージでは、状況が異なります。パッケージを構築するときに、アセットをビルドします。LinuxパッケージでGitLabをインストールすると、変換されたアセットはすでにそこにあります。そのため、パッケージからGitLabをインストールするときにrake assets:precompileを実行する必要はありません。

gitlab-rake assets:precompileがアクセス許可エラーで失敗した場合、セキュリティの観点から見て正当な理由で失敗します。アセットを簡単に書き換えることができないという事実は、攻撃者がGitLabサーバーを使用して、GitLabサーバーの訪問者に悪意のあるJavaScriptコードを提供することを困難にします。

カスタム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

エラー: Short read or OOM loading DB

古いRedisセッションのクリーニングを試してください。

エラー: 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)

apt-cacher-ngと、この変更が必要な理由の詳細については、packagecloudブログを参照してください。

apt-mirrorを使用して複数のディストリビューションのパッケージをミラーリングすると失敗する

GitLab CEとGitLab EEのdebパッケージは、ディストリビューション全体で同じバージョン文字列を共有しますが、内部のコンテンツが異なります。Debianリポジトリ形式では、これらは重複パッケージとして扱われます。これは、1つのdebリポジトリが複数のディストリビューションに安全に対応できないことを意味します。1つのディストリビューションのパッケージメタデータが別のディストリビューションのメタデータを上書きする可能性があるためです。

各ディストリビューションを専用パスで公開します。ただし、https://packages.gitlab.com/gitlab/gitlab-ce/<operating_system> URLへのリクエストを正しいディストリビューションhttps://packages.gitlab.com/gitlab/gitlab-ce/<operating_system>/<distribution>にリダイレクトするURLリダイレクトが設定されています。これにより、ユーザーは異なるディストリビューションに対して同じURLを使用し続けることができます。

ただし、この方法は、apt-mirrorのようなミラーリングツールを使用して同じホストから複数のディストリビューションをミラーリングする場合には機能しません。そのため、誤ったディストリビューションのメタデータまたはパッケージをフェッチする可能性があります。

URLパスにディストリビューションを明示的に追加してください。たとえば、Jammyの場合は次のようになります:

deb https://packages.gitlab.com/gitlab/gitlab-ce/ubuntu/jammy jammy main
deb https://packages.gitlab.com/gitlab/gitlab-ee/ubuntu/jammy jammy main
deb https://packages.gitlab.com/gitlab/gitlab-fips/ubuntu/jammy jammy main

この形式では、キーの場所は次のとおりです:

  • InReleaseはhttps://packages.gitlab.com/gitlab/gitlab-ce/ubuntu/jammy/dists/jammy/InReleaseにあります。
  • Packages.gzはhttps://packages.gitlab.com/gitlab/gitlab-ce/ubuntu/jammy/dists/jammy/main/binary-amd64/Packages.gzにあります。
  • パッケージファイルはhttps://packages.gitlab.com/gitlab/gitlab-ce/ubuntu/jammy/pool/main/g/gitlab-ce/gitlab-ce_18.5.0-ce.0_amd64.debにあります。

gitlab-runner

gitlab-runnerパッケージの構成は、同じパッケージが複数のディストリビューションで使用されるため、異なります。URLはhttps://packages.gitlab.com/runner/gitlab-runnerのままにすることができます。

自己署名証明書またはカスタム認証局の使用

カスタム認証局を持つ分離されたネットワークにGitLabをインストールする場合、または自己署名証明書を使用する場合は、証明書がGitLabから到達できることを確認してください。そうしないと、次のようなエラーが発生します:

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

GitLabがGitLab Shellのような内部サービスに接続しようとすると発生します。

これらのエラーを修正するには、カスタム公開証明書のインストールセクションを参照してください。

エラー: 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の前にプロキシがあり、パッケージでデフォルトで設定されているプロキシヘッダーが環境に対して正しくありません。

NGINXドキュメントのデフォルトプロキシヘッダーセクションの変更で、デフォルトヘッダーをオーバーライドする方法について詳しく説明しています。

CSRFトークンの信頼性を確認できませんでした完了422処理できません

ほとんどの場合、GitLabの前にプロキシがあり、パッケージでデフォルトで設定されているプロキシヘッダーが環境に対して正しくありません。

NGINXドキュメントのデフォルトプロキシヘッダーセクションの変更で、デフォルトヘッダーをオーバーライドする方法について詳しく説明しています。

拡張機能pg_trgmがありません

GitLabにはPostgreSQL拡張機能pg_trgmが必要です。バンドルされたデータベースを含むLinuxパッケージを使用している場合、アップグレード時に拡張機能が自動的に有効になります。

ただし、外部（パッケージ化されていない）データベースを使用している場合は、拡張機能を手動で有効にする必要があります。この理由として、外部データベースを使用するLinuxパッケージインスタンスには、拡張機能が存在するかどうかを確認する方法がなく、拡張機能を有効にする方法もないことが挙げられます。

この問題を修正するには、まず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がアップグレードまたはバックアップの実行時に正常に動作する場合は、スワップを追加すると問題が解決するはずです。通常の実行中にサーバーがスワップを使用している場合は、RAMを追加してパフォーマンスを向上させることができます。

NGINXエラー：could not build server_names_hash, you should increase server_names_hash_bucket_size

GitLabの外部URLがデフォルトのバケットサイズ（64バイト）よりも長い場合、NGINXが動作を停止し、ログにこのエラーが表示されることがあります。より大きなサーバー名を許可するには、/etc/gitlab/gitlab.rbのバケットサイズを2倍にします:

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は、basic.targetではなくmulti-user.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コンテナでのInitデーモンの検出

Dockerコンテナでは、GitLabパッケージは/.dockerenvファイルの存在を検出し、initシステムの自動検出をスキップします。ただし、非Dockerコンテナ（containerd、cri-oなど）では、そのファイルが存在せず、パッケージはsysvinitにフォールバックするため、インストールで問題が発生する可能性があります。これを回避するために、ユーザーはgitlab.rbファイルに次の設定を追加して、initデーモンの検出を明示的に無効にすることができます:

package['detect_init'] = false

この構成を使用する場合、gitlab-ctl reconfigureを実行する前に、runsvdir-startコマンドを使用してrunitサービスを開始する必要があります:

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

AWS Cloudformationの使用中にgitlab-ctl reconfigureがハングする

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の起動時に、次のようなエラーが見られる場合:

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サービスはネットワーク接続を確立できません。

これは、ホストをIPv4アドレスではなくIPv6アドレスに解決するために、DNS構成（または/etc/hosts）を修正することで解決できます。

エラー：... bad component(expected host component: my_url.tld) external_urlにアンダースコアが含まれている場合

external_urlをアンダースコアで設定した場合（たとえば、https://my_company.example.com）、CI/CDで次の問題が発生する可能性があります:

  • プロジェクトの設定 > CI/CDページを開くことができなくなります。
  • Runnerはジョブを選択せず、エラー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でアンダースコアを使用しないでください。それについては未解決の問題があります: アンダースコア付きのexternal_urlを設定すると、GitLab CI/CD機能が破損する。

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

詳細については、issue 341573を参照してください。

GitLabの再インストール時に再構成がスタックする

既知の問題のため、GitLabをアンインストールして再度インストールしようとした後、再構成プロセスがruby_block[wait for logrotate service socket] action runでスタックすることがあります。この問題は、GitLabをアンインストールするときに、systemctlコマンドの1つが実行されない場合に発生します。

この問題を解決するには:

  • GitLabをアンインストールするときは、すべての手順に従い、必要に応じて実行してください。
  • issue 7776の回避策に従ってください。

PulpまたはRed Hat SatelliteでのGitLab yumリポジトリのミラーリングが失敗する

PulpまたはRed Hat Satelliteを使用したhttps://packages.gitlab.com/gitlab/にあるLinuxパッケージのyumリポジトリの直接ミラーリングは、同期時に失敗します。異なるソフトウェアによって異なるエラーが発生します:

  • Pulp 2またはSatellite < 6.10は、"Malformed repository: metadata is specified for different set of packages in filelists.xml and in other.xml"エラーで失敗します。
  • Satellite 6.10は、"pkgid"エラーで失敗します。
  • Pulp 3またはSatellite > 6.10は成功するようですが、リポジトリメタデータのみが同期されます。

これらの同期の失敗は、GitLab yumミラーリポジトリ内のメタデータに関する問題が原因です。このメタデータには、通常はリポジトリ内のすべてのRPMのファイルのリストを含むfilelists.xml.gzファイルが含まれています。GitLab yumリポジトリは、ファイルが完全に入力された場合に発生するサイズの問題を回避するために、このファイルをほとんど空のままにします。

各GitLab RPMには膨大な数のファイルが含まれており、リポジトリ内の多数のRPMを掛けると、完全に入力された場合、巨大なfilelists.xml.gzファイルになります。ストレージとビルドの制約のため、ファイルを作成しますが、入力しません。空のファイルにより、PulpおよびRedHat Satellite（Pulpを使用）ファイルのリポジトリのミラーリングに失敗します。

詳細については、issue 2766を参照してください。

問題を回避策する

問題を回避策するには:

  1. reposyncやcreaterepoなどの代替RPMリポジトリミラーリングツールを使用して、公式のGitLab yumリポジトリのローカルコピーを作成します。これらのツールは、完全に入力されたfilelists.xml.gzファイルの作成を含む、ローカルデータ内のリポジトリメタデータを再作成します。
  2. PulpまたはSatelliteをローカルミラーにポイントします。

ローカルミラーの例

次に、ローカルミラーリングを実行する方法の例を示します。この例では、以下を使用します:

  • ApacheをリポジトリのWebサーバーとして使用します。
  • reposyncおよびcreaterepoを使用して、GitLabリポジトリをローカルミラーに同期します。このローカルミラーは、PulpまたはRedHat Satelliteのソースとして使用できます。Cobblerなどの他のツールも使用できます。

この例では:

  • ローカルミラーは、RHEL 8、Rocky 8、またはAlmaLinux 8システムで実行されています。
  • Webサーバーに使用されるホスト名はmirror.example.comです。
  • Pulp 3は、ローカルミラーから同期します。
  • GitLab Enterprise Editionリポジトリのミラーリングです。

Apacheサーバーを作成および構成する

次の例は、1つ以上のYumリポジトリミラーをホストするために、基本的なApache 2サーバーをインストールおよび構成する方法を示しています。Webサーバーの構成とセキュリティ保護の詳細については、Apacheドキュメントを参照してください。

  1. httpdをインストールします。

    sudo dnf install httpd

  2. /etc/httpd/conf/httpd.confにDirectoryスタンザを追加します:

    <Directory "/var/www/html/repos">
Options All Indexes FollowSymLinks
Require all granted
</Directory>

  3. httpd構成を完了します:

    sudo rm -f /etc/httpd/conf.d/welcome.conf
sudo mkdir /var/www/html/repos
sudo systemctl enable httpd --now

ミラーリングされたYumリポジトリのURLを取得します

  1. GitLabリポジトリのyum構成ファイルをインストールします:

    curl "https://packages.gitlab.com/install/repositories/gitlab/gitlab-ee/script.rpm.sh" | sudo bash
sudo dnf config-manager --disable gitlab_gitlab-ee gitlab_gitlab-ee-source

  2. リポジトリURLを取得します:

    sudo dnf config-manager --dump gitlab_gitlab-ee | grep baseurl
baseurl = https://packages.gitlab.com/gitlab/gitlab-ee/el/8/x86_64

    baseurlの内容をローカルミラーのソースとして使用します。例: https://packages.gitlab.com/gitlab/gitlab-ee/el/8/x86_64。

ローカルミラーを作成する

  1. createrepoパッケージをインストールします:

    sudo dnf install createrepo

  2. reposyncを実行して、RPMをローカルミラーにコピーします:

    sudo dnf reposync --arch x86_64 --repoid=gitlab_gitlab-ee --download-path=/var/www/html/repos --newest-only

    --newest-onlyオプションは、最新のRPMのみをダウンロードします。このオプションを省略すると、リポジトリ内のすべてのRPM（約1 GB）がダウンロードされます。

  3. createrepoを実行して、リポジトリメタデータを再作成します:

    sudo createrepo -o /var/www/html/repos/gitlab_gitlab-ee /var/www/html/repos/gitlab_gitlab-ee

ローカルミラーリポジトリは、http://mirror.example.com/repos/gitlab_gitlab-ee/で使用できるはずです。

ローカルミラーを更新する

新しいGitLabバージョンがリリースされたら、新しいRPMを取得するために、ローカルミラーを定期的に更新する必要があります。これを行う1つの方法は、cronを使用することです。

次の内容で/etc/cron.daily/sync-gitlab-mirrorを作成します:

#!/bin/sh

dnf reposync --arch x86_64 --repoid=gitlab_gitlab-ee --download-path=/var/www/html/repos --newest-only --delete
createrepo -o /var/www/html/repos/gitlab_gitlab-ee /var/www/html/repos/gitlab_gitlab-ee

dnf reposyncコマンドで使用される--deleteオプションは、対応するGitLabリポジトリに存在しなくなったローカルミラー内のRPMを削除します。

ローカルミラーを使用する

  1. Pulp repositoryとremoteを作成します:

    pulp rpm repository create --retain-package-versions=1 --name "gitlab-ee"
pulp rpm remote create --name gitlab-ee --url "http://mirror.example.com/repos/gitlab_gitlab-ee/" --policy immediate
pulp rpm repository update --name gitlab-ee --remote gitlab-ee

  2. リポジトリを同期します:

    pulp rpm repository sync --name gitlab-ee

    このコマンドは、GitLabリポジトリへの変更でローカルミラーを更新するために、定期的に実行する必要があります。

リポジトリが同期されたら、公開と配布を作成して使用できるようにすることができます。詳細については、https://docs.pulpproject.org/pulp_rpm/を参照してください。

エラー: E: connection refused to d20rj4el6vkp4c.cloudfront.net 443

packages.gitlab.comでパッケージリポジトリでホストされているパッケージをインストールすると、クライアントはCloudFrontアドレスd20rj4el6vkp4c.cloudfront.netへのリダイレクトを受信して従います。エアギャップ環境のサーバーは、次のエラーを受信する可能性があります:

E: connection refused to d20rj4el6vkp4c.cloudfront.net 443
Failed to connect to d20rj4el6vkp4c.cloudfront.net port 443: Connection refused

この問題を解決するには、3つのオプションがあります:

  • ドメインで許可リストに登録できる場合は、エンドポイントd20rj4el6vkp4c.cloudfront.netをファイアウォール設定に追加します。
  • ドメインで許可リストに登録できない場合は、CloudFront IPアドレス範囲をファイアウォール設定に追加します。このリストは変更される可能性があるため、ファイアウォール設定と同期しておく必要があります。
  • パッケージファイルをパッケージを手動でダウンロードして、サーバーにアップロードします。

エラー：503 Service Unavailableパッケージストレージ操作でサービスを利用できません

一部のパッケージストレージコンポーネントは、Google Cloud Storage（GCS）を介して提供されます。これらのコンポーネントは、パブリックAPTリポジトリエンドポイントに加えて、GCSエンドポイントへの送信HTTPSアクセスを必要とします。apt updateが503 Service Unavailableエラーで失敗した場合、storage.googleapis.com/packages-opsへのアクセスがブロックされています。

このエラーを解決するには、ファイアウォールルールで、次のエンドポイントへの送信HTTPS（ポート443）接続が許可されていることを確認してください:

  • packages.gitlab.com
  • storage.googleapis.com
  • Google Cloud Storageのpackages-opsバケット

net.core.somaxconnが低すぎないか確認してください

以下は、net.core.somaxconnの値が低すぎるかどうかを識別するのに役立つ場合があります:

$ netstat -ant | grep -c SYN_RECV
4

netstat -ant | grep -c SYN_RECVからの戻り値は、確立されるのを待機している接続の数です。値がnet.core.somaxconnより大きい場合:

$ sysctl net.core.somaxconn
net.core.somaxconn = 1024

タイムアウトまたはHTTP 502エラーが発生する可能性があり、gitlab.rbのpuma['somaxconn']変数を更新して、この値を大きくすることをお勧めします。

エラー：exec request failed on channel 0またはshell request failed on channel 0

Git over SSHを使用してプルまたはプッシュすると、次のエラーが表示される場合があります:

  • exec request failed on channel 0
  • shell request failed on channel 0

これらのエラーは、gitユーザーからのプロセス数が制限を超えている場合に発生する可能性があります。

このイシューを解決するには、次の手順を実行します:

  1. gitlab-shellが実行されているノードの/etc/security/limits.confファイルで、gitユーザーのnproc設定を増やします。通常、gitlab-shellはGitLab Railsノードで実行されます。
  2. プルまたはプッシュGitコマンドを再試行します。

SSH接続が失われた後のインストールハング

リモート仮想マシンにGitLabをインストールしていて、SSH接続が失われた場合、インストールがゾンビdpkgプロセスでハングする可能性があります。インストールを再開するには:

  1. topを実行して、関連付けられているaptプロセスのプロセスIDを見つけます。これは、dpkgプロセスの親です。
  2. sudo kill <PROCESS_ID>を実行して、aptプロセスを強制終了します。
  3. フレッシュインストールを実行する場合のみ、sudo gitlab-ctl cleanseを実行します。この手順では、既存のデータが消去されるため、アップグレードには使用しないでください。
  4. sudo dpkg configure -aを実行します。
  5. 目的の外部URLと、不足している可能性のあるその他の設定を含めるように、gitlab.rbファイルを編集します。
  6. sudo gitlab-ctl reconfigureを実行します。

GitLabを再設定する際に、次のエラーが発生する可能性があります:

RuntimeError: redis_service[redis] (redis::enable line 19) had an error: RuntimeError: ruby_block[warn pending redis restart] (redis::enable line 77) had an error: RuntimeError: Execution of the command /opt/gitlab/embedded/bin/redis-cli -s /var/opt/gitlab/redis/redis.socket INFO failed with a non-zero exit code (1)

エラーメッセージは、redis-cliとの接続を確立しようとしているときに、Redisが再起動またはシャットダウンされた可能性があることを示しています。レシピがgitlab-ctl restart redisを実行し、すぐにバージョンを確認しようとすることを考えると、エラーを引き起こす競合状態が発生する可能性があります。

この問題を解決するには、次のコマンドを実行します:

sudo gitlab-ctl reconfigure

それが失敗した場合は、gitlab-ctl tail redisの出力を確認し、redis-cliを実行してみてください。