GitLab Runnerのトラブルシューティング

このセクションは、GitLab Runnerのトラブルシューティングの際に役立ちます。

一般的なトラブルシューティング

以下は、一般的なランナーのトラブルシューティングに関するものです。

coordinator とはどういう意味ですか？

coordinator はジョブをリクエストする GitLab インストールです。

言い換えれば、runnerは、coordinatorによって要求されたジョブをピックアップする分離された（仮想）マシンです。

サービスとして実行した場合、ログはどこに保存されますか？

  • GitLab RunnerがLinux/MacOS上でサービスとして実行されている場合、デーモンはsyslogにログを記録します。
  • GitLab RunnerがWindows上でサービスとして実行されている場合、システムのイベントログに記録されます。

--debug モードでの実行

GitLab Runnerをデバッグ/verboseモードで実行することは可能ですか？ ターミナルから実行してください： 

gitlab-runner --debug run

私が見ているのはx509: certificate signed by unknown authority

自己署名証明書をご覧ください。

にアクセスするとPermission Denied が表示されます。/var/run/docker.sock

Dockerのexecutorを使用したい場合、サーバにインストールされたDocker Engineに接続すると、Permission Denied のエラーが表示されます。 最も可能性の高い原因は、システムがSELinux（CentOS、Fedora、RHELではデフォルトで有効）を使用していることです。 あなたのシステムのSELinuxポリシーを確認して、拒否の可能性がないか確認してください。

Javaプロジェクトのビルド時にDocker executorがタイムアウトする問題

これは、AUFSストレージ・ドライバが壊れているために起こる可能性が高いです。

Dockerの設定と実行についてはこちらの記事を、systemdによる制御と設定についてはこちらの記事をご覧ください。

アーティファクトのアップロード中に411が表示されます。

これはrunnerがTransfer-Encoding: chunked 。これはNGINXの初期バージョン(https://serverfault.com/questions/164220/is-there-a-way-to-avoid-nginx-411-content-length-required-errors)では壊れています。

NGINXを新しいバージョンにアップグレードしてください。 詳細については、このイシューを参照してください：https://gitlab.com/gitlab-org/gitlab-runner/-/issues/1031

warning: You appear to have cloned an empty repository.

HTTP(s) を使ってgit clone を実行するとき（GitLab Runner を使うか、手動でテストするとき）、次のような出力が表示されます： 

$ git clone https://git.example.com/user/repo.git

Cloning into 'repo'...
warning: You appear to have cloned an empty repository.

GitLabサーバーのインストールでHTTP Proxyの設定が正しく行われていることを確認してください。 特に、独自の設定を持つHTTP Proxyを使用している場合は、GitLabのリクエストがGitLabUnicornソケットではなく、GitLab Workhorseソケットにプロキシされることを確認してください。

HTTP(S) 経由のGitプロトコルはGitLab Workhorseによって解決されるので、これがGitLabの主なエントリポイントです。

Omnibus GitLabを使用しているが、バンドルされているNGINXサーバーを使用したくない場合は、バンドルされていないWebサーバーを使用するをお読みください。

GitLab Recipesリポジトリには、ApacheとNGINXのウェブサーバー設定例があります。

ソースからインストールしたGitLabを使用している場合は、上記のドキュメントと例も読み、すべてのHTTP(S) トラフィックがGitLab Workhorseを経由していることを確認してください。

ユーザーのイシューの例をご覧ください。

zoneinfo.zip: no such file or directory エラーは、Timezone またはOffPeakTimezone

[[docker.machine.autoscaling]] この機能は、ほとんどのUnixシステムですぐに動作するはずです。しかし、いくつかのUnixシステム、そしておそらくほとんどの非Unixシステム（Runnerのバイナリを提供しているWindowsを含む）では、Runnerを使用すると、開始時に次のようなエラーでクラッシュします： 

Failed to load config Invalid OffPeakPeriods value: open /usr/local/go/lib/time/zoneinfo.zip: no such file or directory

このエラーはGoのtime パッケージが原因です。 Goは指定されたタイムゾーンの設定をロードするためにIANAタイムゾーンデータベースを使用します。 ほとんどのUnixシステムでは、このデータベースはよく知られたパス(/usr/share/zoneinfo,/usr/share/lib/zoneinfo,/usr/lib/locale/TZ/)のいずれかにすでに存在します。 Goのtime パッケージは、これら3つのパスすべてからタイムゾーンデータベースを探します。 そのどれもが見つからなかった場合でも、マシンにGo開発環境が設定されている場合は、$GOROOT/lib/time/zoneinfo.zip ファイルにフォールバックします。

これらのパスが1つも存在しない場合（たとえば、本番Windowsホスト上）、上記のエラーが発生します。

お使いのシステムがIANAタイムゾーンデータベースをサポートしているが、デフォルトでは利用できない場合は、インストールしてみてください。 Linuxシステムの場合は、例えば以下の方法でインストールできます： 

# on Debian/Ubuntu based systems
sudo apt-get install tzdata

# on RPM based systems
sudo yum install tzdata

# on Linux Alpine
sudo apk add -U tzdata

お使いのシステムがこのデータベースを_ネイティブな_方法で提供していない場合は、以下の手順でOffPeakTimezoneを動作させることができます：

  1. zoneinfo.zipのダウンロード . バージョンv9.1.0から、タグ付きパスからファイルをダウンロードできるようになりました。その場合、zoneinfo.zip のダウンロードURLで、latest をタグ名（例えば、v9.1.0）に置き換えてください。

  2. このファイルをよく知られているディレクトリに保存します。config.toml ファイルが存在するのと同じディレクトリを使用することをお勧めします。例えば、WindowsマシンでRunnerをホストしていて、設定ファイルがC:\gitlab-runner\config.tomlに保存されている場合、zoneinfo.zipをC:\gitlab-runner\zoneinfo.zipに保存します。

  3. zoneinfo.zip ファイルへのフルパスを含むZONEINFO 環境変数を設定します。run コマンドを使用して Runner を起動する場合は、次のようにします： 

    ZONEINFO=/etc/gitlab-runner/zoneinfo.zip gitlab-runner run <other options ...>

    またはWindowsを使用している場合： 

    C:\gitlab-runner> set ZONEINFO=C:\gitlab-runner\zoneinfo.zip
C:\gitlab-runner> gitlab-runner run <other options ...>

    システムサービスとしてRunnerを起動している場合、サービスマネージャーソフトウェア（UNIXシステム）またはシステム設定（Windows）からRunnerのユーザーが使用できる環境変数のリストにZONEINFO 変数を追加して、サービス設定を更新/上書きする必要があります。

なぜ Runner のインスタンスを複数実行できないのですか？

可能ですが、同じconfig.toml ファイルを共有することはできません。

同じ設定ファイルを使用して複数のRunnerインスタンスを実行すると、予期しない動作やデバッグしにくい動作が発生することがあります。 GitLabRunner 12.2では、一度に特定のconfig.toml ファイルを使用できるRunnerインスタンスは1つだけです。

Job failed (system failure): preparing environment:

このエラーは多くの場合、shellがプロファイルを読み込んでいて、スクリプトの1つが失敗の原因になっています。

失敗の原因となることが知られているドットファイルの例：

  • .bash_logout
  • .condarc
  • .rvmrc

Windowsのトラブルシューティング

以下は、Windows上のRunnerのトラブルシューティングに関するものです。

Windows でビルド中に PathTooLongException が発生します。

これは、npm のようなツールが、260文字以上のパスを持つディレクトリ構造を生成してしまうために起こります。この問題を解決するために、2つの修正が考えられます。

a) core.longpathsを有効にしてgitを使用します。

まずコマンドラインからgit config --system core.longpaths true を実行し、GitLab CI のプロジェクト設定ページからgit fetch を使うようにプロジェクトを設定してください。

b) PowerShell用のNTFSSecurityツールを使用します。

NTFSSecurityPowerShellモジュールは、長いパスをサポートするRemove-Item2メソッドを提供します。 GitLab CI Multi Runnerは、それが利用可能な場合、それを検出し、自動的にそれを使用します。

WindowsのBashスクリプトを実行できません。The system cannot find the batch label specified - buildscript

call C:\path\to\test.batのように見えるように、.gitlab-ci.yml のバッチファイル行の先頭にcall を追加する必要があります。以下は、より完全な例です： 

before_script:
  - call C:\path\to\test.bat

詳細はイシュー#1025をご覧ください。

ウェブターミナルで色のついた出力を得るにはどうすればよいですか？

短い答えです：

プログラムの出力にANSIカラーコードがあることを確認してください。 テキストのフォーマットのために、UNIXのANSIターミナルエミュレータで実行していると仮定してください（WebUIの出力がそうなっているからです）。

長い答えです：

GitLab CI のウェブインターフェイスは UNIX ANSI ターミナルを（少なくとも部分的に）エミュレートしています。gitlab-runner はビルドからの出力をウェブインターフェイスに直接パイプします。 つまり、ANSI カラーコードがあれば、それに従います。

Windows の CMD 端末の古いバージョン（Win10 バージョン 1511 以前）は ANSI カラーコードをサポートしていません - 代わりに win32 (ANSI.SYS) 呼び出しを使いますが、これは表示する文字列には存在しません。 クロスプラットフォームのプログラムを書く場合、開発者は通常デフォルトで ANSI カラーコードを使い、Windows システム上で実行するときに win32 呼び出しに変換します（例:Colorama）。

もし、あなたのプログラムが上記のことを行っているのであれば、ANSIコードが文字列の中に残るように、CIビルドではその変換を無効にする必要があります。

PowerShell を使った例については GitLab CI YAML ドキュメントを、詳細についてはイシュー#332を参照してください。

The service did not start due to a logon failure サービス開始時のエラー

WindowsでGitLab Runnerサービスをインストールして起動すると、このようなエラーが発生することがあります： 

gitlab-runner install --password WINDOWS_MACHINE_PASSWORD
gitlab-runner start
FATA[0000] Failed to start GitLab Runner: The service did not start due to a logon failure.

このエラーは、サービスの実行に使用されるユーザーにSeServiceLogonRight 権限がない場合に発生する可能性があります。このような場合は、選択したユーザーにこの権限を追加してから、サービスを再度起動してみてください。

SeServiceLogonRight 、2つの方法で追加できます：

  1. 管理ツールを手動で使用します：
    • コントロールパネル」>「システムと_セキュリティ」>「管理ツール_」を開きます、
    • _ローカルセキュリティポリシーツールを_開きます、
    • 左側のリストで、[セキュリティ_設定] > [ローカルポリシー] > [ユーザー権限の割り当て_] を選択します、
    • 右側のリストにある「サービスとしてログオン」を開きます、
    • ユーザーまたはグループの追加…ボタンをクリックします、

    • ユーザーを追加し（「手入力」または「詳細設定…」ボタンを使用）、設定を適用します。

      Windows Vista、Windows Server 2008、Windows 7、Windows 8.1、Windows Server 2008 R2、Windows Server 2012 R2、Windows Server 2012、Windows 8。

      注意:Windowsのバージョンによっては、_ローカルセキュリティポリシーツールが_利用できない場合があります。

  2. コマンドラインから、Ntrights.exe ツールを使用します：
    • マイクロソフトのダウンロードサイトからツールをダウンロードしてください、

    • ntrights.exe ntrights +r SeServiceLogonRight -u USER_NAME_HERE を実行します（ntrights.exe 実行ファイルのフルパスを指定するか、システムのPATH 環境変数にそのパスを追加する必要があることを覚えておいてください）。

      注意：このツールは2003年に作成され、当初はWindows XPとWindows Server 2003で使用するように設計されていました。マイクロソフトのサイトでは、Windows 7とWindows Server 2008 R2に適用する使用例Ntrights.exe 。この解決策はテストされておらず、ソフトウェアの古さのため、最新のWindowsバージョンでは動作しない可能性があります。

サービス・コンフィギュレーションで使用されているユーザーのSeServiceLogonRight を追加した後、コマンドgitlab-runner start は失敗することなく終了し、サービスは正しく開始されるはずです。

Kubernetesのexecutorを使用して、成功としてマークされたジョブが途中で終了した場合

ジョブ実行をご覧ください。

MacOSトラブルシューティング

以下は、MacOS上のRunnerのトラブルシューティングに関するものです。

"launchctl" failed: exit status 112, Could not find domain for

このメッセージは、MacOSにGitLab Runnerをインストールしようとすると表示されることがあります。 SSH接続ではなく、GUIターミナルアプリケーションからGitLab Runnerサービスを管理することを確認してください。

Failed to authorize rights (0x1) with status: -60007.

MacOSを使用しているときにRunnerが上記のメッセージで止まってしまう場合、2つの原因が考えられます：

  1. ユーザーがUIインタラクションを実行できるようにしましょう： 

    DevToolsSecurity -enable
sudo security authorizationdb remove system.privilege.taskport is-developer

    最初のコマンドは開発者ツールへのアクセスを可能にし、2番目のコマンドは開発者グループのメンバーであるユーザがUIインタラクション、例えばiOSシミュレータを実行することを可能にします。

  2. RunnerサービスがSessionCreate = trueを使っていないことを確認してください。以前は、GitLab Runnerをサービスとして実行する場合、SessionCreateを使ってLaunchAgents を作成していました。その時点（Mavericks）では、これがコード署名を機能させるための唯一の解決策でした。最近、OS X El Capitanで多くの新しいセキュリティ機能が導入され、この動作が変更されました。 GitLab Runner 1.1以降、LaunchAgentを作成する場合、SessionCreateを設定しません。しかし、アップグレードするには、LaunchAgent スクリプトを手動で再インストールする必要があります： 

    gitlab-runner uninstall
gitlab-runner install
gitlab-runner start

    そして、~/Library/LaunchAgents/gitlab-runner.plist がSessionCreate をfalseに設定していることを確認できます。

fatal: unable to access 'https://path:3000/user/repo.git/': Failed to connect to path port 3000: Operation timed out ジョブエラー

いずれかのジョブがこのエラーで失敗した場合は、RunnerがGitLabインスタンスに接続できることを確認してください。 接続がブロックされている可能性があります：

  • ファイアウォール
  • 代理人
  • 権限
  • ルーティング設定