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

ランナーのステータスを確認する

ランナーのステータスは、ワークスペースまたはリポジトリに関連付けられている [ランナー] ページで確認できます。

  • ワークスペース ランナーのステータスを確認するには、ワークスペースの左サイドバーで [設定]、左サイドバー ナビゲーションの [パイプライン] にある [ワークスペース ランナー] の順に選択します。

  • リポジトリ ランナーのステータスを確認するには、リポジトリの左サイドバーで [リポジトリの設定]、左サイドバー ナビゲーションの [パイプライン] にある [ランナー] の順に選択します。

ステータスは、次のいずれかになります。

  • 未登録: ランナーは作成されましたが実行されませんでした。注: ランナーが 1 週間以内に登録されない場合、そのランナーは削除されます。

  • オンライン: ランナーは稼働しており、ステップのスケジュールに利用できます。

  • オフライン: ランナーは利用できません。停止されているか、ネットワーク接続の問題がある可能性があります

  • 無効: ランナーは一時的に無効になっていたため、再度有効になるまでステップはスケジュールされません。

オンライン ステータスを含むユーザー インターフェイスのランナー表示

ランナーのログを確認する

ステップのビルドとサービスの各ログ (ランナーのログは除く) は、ステップが完了するとランナー ホストから削除されます。これらのログは、パイプラインのユーザー インターフェイスのステップ ログにあります。

ランナーのログ ファイルの場所は、オペレーティング システムとランナーのタイプ間によって異なります。

Linux Docker ランナーのログ ファイルを確認する

  1. 影響を受けるランナーをホストしている Linux デバイスにアクセスします。

  2. Open the runner.log file using a text editor. This log file is stored in the runners' working directory, in a subdirectory named using the runners' UUID (a 32-character hexadecimal string). Such as:

    1 <runner_working_directory>/<runnerUuid>/runner.log

    例:

    1 /tmp/b609961f-891e-c872-c36b-f3f2c315d186/runner.log

    The default working directory for the runner is the /tmp directory.

  3. ログ ファイルの最後で対処が必要なエラーを確認します。

Windows PowerShell ランナーのログ ファイルを確認する

  1. 影響を受けるランナーをホストしている Windows デバイスにアクセスします。

  2. Using PowerShell or File Explorer, navigate to the runner installation directory (atlassian-bitbucket-pipelines-runner). This directory will be stored where PowerShell was working when the runner was started.
    For example: if PowerShell was working in the users' home directory, such as:

    1 PS C:\Users\Username>

    The runner installation directory would be C:\Users\Username\atlassian-bitbucket-pipelines-runner\

  3. Open the runner.log file using a text editor. This log file is stored in the runners' working directory, in a subdirectory named using the runners' UUID (a 32-character hexadecimal string). Such as:

    1 <runner_working_directory>\<runnerUuid>\runner.log

    例:

    1 .\atlassian-bitbucket-pipelines-runner\temp\b609961f-891e-c872-c36b-f3f2c315d186\runner.log

    The default working directory for the runner is the \temp subdirectory of the atlassian-bitbucket-pipelines-runner directory.

  4. ログ ファイルの最後で対処が必要なエラーを確認します。

macOS シェル ランナーのログ ファイルを確認する

  1. 影響を受けるランナーをホストしている macOS デバイスにアクセスします。

  2. Using Terminal or Finder, navigate to the runner installation directory (atlassian-bitbucket-pipelines-runner). This directory will be stored where Terminal was working when the runner was started.
    For example: if Terminal was working in the users' home directory (~/), such as: /Users/Username/; the runner installation directory would be /Users/Username/atlassian-bitbucket-pipelines-runner/

  3. Open the runner.log file using a text editor. This log file is stored in the runners' working directory, in a subdirectory named using the runners' UUID (a 32-character hexadecimal string). Such as:

    1 <runner_working_directory>/<runnerUuid>/runner.log

    例:

    1 ~/atlassian-bitbucket-pipelines-runner/temp/b609961f-891e-c872-c36b-f3f2c315d186/runner.log

    The default working directory for the runner is the /temp subdirectory of the atlassian-bitbucket-pipelines-runner directory.

  4. ログ ファイルの最後で対処が必要なエラーを確認します。

ランナーのバージョンを更新する

ランナーで問題が発生した場合は、ランナーを最新バージョンに更新してください。

  1. ランナーを停止します。

  2. 以下のコマンドを使用して、最新のランナー バージョンをプルします。

    1 docker image pull docker-public.packages.atlassian.com/sox/atlassian/bitbucket-pipelines-runner:1
  3. ランナーを再起動します。

ランナー起動時のエラーのトラブルシューティング

エラー メッセージ

ソリューション

docker: Error response from daemon: Conflict. The container name "/runner-76b247e7-b925-5e7b-9da2-1cda14c4ff2c" is already in use by container "c3403236e3af5962ed3a9b8771561bd2021974941cc8a89a40c6c66cecb18f53". You have to remove (or rename) that container to be able to reuse that name.
See 'docker run --help'.

Run the command docker container rm -f <runner-name>. Replace the placeholder <runner-name> with the actual name.
For example, for the error message used in this example, you would run docker container rm -f runner-76b247e7-b925-5e7b-9da2-1cda14c4ff2c command.

The installed Docker client must be at least version 19

必要なバージョンの Docker エンジンをインストールするには「Docker エンジンのインストールのヘルプ」をご確認ください。

No access to containers directory

Run the following command to add read permissions to the current user:
sudo chmod +r /var/lib/docker/containers

user-ns remapping not allowed in docker settings.

user-ns の再マッピングはサポートされていません。Docker デーモンの設定を変更してください。詳細については、Docker ドキュメント「ユーザーの名前空間を持つコンテナーを分離する」をご確認ください。

The docker logging driver must be json-file.

Docker のドキュメント - ロギング ドライバーを設定する」をご確認ください。

failed to start daemon: error initializing graphdriver: overlay2: the backing xfs filesystem is formatted without d_type support, which leads to incorrect behavior. Reformat the filesystem with ftype=1 to enable d_type support. Backing filesystems without d_type support are not supported.

Docker ドキュメント - OverlayFS ストレージ ドライバーを使用する」をご確認ください。

.\start.ps1 : File C:\Users\Administrator\atlassian-bitbucket-pipelines-runner\bin\start.ps1 cannot be loaded. The file C:\Users\Administrator\atlassian-bitbucket-pipelines-runner\bin\start.ps1 is not digitally signed. You cannot run this script on the current system. For more information about running scripts and setting execution policy, see about_Execution_Policies at https:/go.microsoft.com/fwlink/?LinkID=135170

未署名のスクリプトを PowerShell で実行することを許可します

ステップ実行時のエラーのトラブルシューティング

エラー メッセージ

ステップ実行ステージ

ソリューション

Cloning into ... fatal: unable to access ... : SSL certificate problem: self signed certificate in certificate chain

クローン

bitbucket-pipelines.yml の git クローンで SSL 検証を無効にしてください

bash: ls: command not found (or any standard bash command)

Building

The command not found error mostly occurs when the PATH environment variable is configured as Workspace/Repository/Deployment variable. The default PATH where the binaries exist get overridden with the user-supplied PATH variable which is causing the error to appear in the build.

{"message":"toomanyrequests: You have reached your pull rate limit. You may increase the limit by authenticating and upgrading: https://www.docker.com/increase-rate-limit"}

イメージをローカルでプルしているとき (レート制限に到達)

  • ホストの Docker Hub にログインして、レート制限を引き上げる

および/または

ランナーが異常な状態にあるため、パイプラインを実行できません。

Issue

ランナーのステータスが [異常] であり、[ランナー] ページに次のメッセージが表示されます。

1 つ以上のランナーが異常な状態にあるため、パイプラインを実行できません。

原因

パイプラインの各ステップの終わりで、ランナーはビルド ディレクトリ (フォルダー) を次のステップの実行前にクリーンアップします。ランナーがこのクリーンアップを実行できない場合は、ランナーは [異常] 状態になります。この問題には次のような原因が考えられます。

  • ビルド ディレクトリ内の 1 つ以上のファイル (またはディレクトリ) の権限によって、ランナーがファイルを削除できません。

  • クリーンアップ時に、プログラムまたはサービスがビルド ディレクトリ内の 1 つ以上のファイル (またはディレクトリ) にアクセスしています。

ソリューション

ランナーによるビルドのクリーンアップ実行を妨げているファイルまたはディレクトリを見つけるには、ランナーのログ ファイルを確認します。次のようなエラーを検索します。

1 An error occurred whilst tearing down directories.

このエラー メッセージの下に、デバッグに使用できる詳細なエラー ログが表示されます。

監査ログ ファイルのアクセス

ステップのビルドとサービスの各ログ (ランナーのログは除く) は、ステップが完了するとランナー ホストから削除されます。これらのログは、パイプラインのユーザー インターフェイスのステップ ログにあります。

ランナーのログ ファイルの場所は、オペレーティング システムとランナーのタイプ間によって異なります。

Linux Docker ランナーのログ ファイルにアクセスする

  1. 影響を受けるランナーをホストしている Linux デバイスにアクセスします。

  2. Open the runner.log file using a text editor. This log file is stored in the runners' working directory, in a subdirectory named using the runners' UUID (a 32-character hexadecimal string). Such as:

    1 <runner_working_directory>/<runnerUuid>/runner.log

    例:

    1 /tmp/b609961f-891e-c872-c36b-f3f2c315d186/runner.log

    The default working directory for the runner is the /tmp directory.

  3. ログ ファイルの最後で対処が必要なエラーを確認します。

ファイルまたはフォルダーの権限を Linux で修正する

In a terminal; fix the permissions on a single file by adding write permissions for the user (u) and the users' user group (g) with the chmod command. Such as:

1 chmod ug+w <path/filename>

To fix the permissions on a directory and its files and subdirectories, add the --recursive option, such as:

1 chmod ug+w --recursive <path/filename>

The chmod command can also be appended to the script of a pipeline step if the permissions issue occurs with every pipeline executed. For example:

1 2 3 4 5 6 7 image: atlassian/default-image:3 pipelines: default: - step: name: 'Step that causes permissions issues' script: - bash ./product-build-script.sh && chmod ug+w --recursive build/

ランナーの設定時に表示されたコマンドを再実行してランナーを再起動するか、ランナーを Bitbucket で再作成します。ランナーのセットアップについては「Linux 用ランナーをセットアップする」をご参照ください。

Windows PowerShell ランナーのログ ファイルにアクセスする

  1. 影響を受けるランナーをホストしている Windows デバイスにアクセスします。

  2. Using PowerShell or File Explorer, navigate to the runner installation directory (atlassian-bitbucket-pipelines-runner). This directory will be stored where PowerShell was working when the runner was started.
    For example: if PowerShell was working in the users' home directory, such as:

    1 PS C:\Users\Username>

    The runner installation directory would be C:\Users\Username\atlassian-bitbucket-pipelines-runner\

  3. Open the runner.log file using a text editor. This log file is stored in the runners' working directory, in a subdirectory named using the runners' UUID (a 32-character hexadecimal string). Such as:

    1 <runner_working_directory>\<runnerUuid>\runner.log

    例:

    1 .\atlassian-bitbucket-pipelines-runner\temp\b609961f-891e-c872-c36b-f3f2c315d186\runner.log

    The default working directory for the runner is the \temp subdirectory of the atlassian-bitbucket-pipelines-runner directory.

  4. ログ ファイルの最後で対処が必要なエラーを確認します。

Windows でファイルまたはフォルダーの権限を修正する

ファイルまたはディレクトリのアクセス権限を修正するには、次のいずれかに従います。

  • ファイルの [プロパティ] ダイアログをファイル エクスプローラーから開いて、クリーンアップを妨げているファイルまたはフォルダーに対する現在のユーザーのユーザー権限を [フル アクセス] に更新します。

  • Use the PowerShell Set-Acl command to provide write and delete access to the files or folders preventing cleanup. For information on using the Set-Acl command, visit Microsoft Docs — PowerShell Set-Acl cmdlet.

ランナーの設定時に表示されたコマンドを再実行してランナーを再起動するか、ランナーを Bitbucket で再作成します。ランナーのセットアップについては「Windows 用ランナーをセットアップする」をご参照ください。

macOS シェル ランナーのログ ファイルにアクセスする

  1. 影響を受けるランナーをホストしている macOS デバイスにアクセスします。

  2. Using Terminal or Finder, navigate to the runner installation directory (atlassian-bitbucket-pipelines-runner). This directory will be stored where Terminal was working when the runner was started.
    For example: if Terminal was working in the users' home directory (~/), such as: /Users/Username/; the runner installation directory would be /Users/Username/atlassian-bitbucket-pipelines-runner/

  3. Open the runner.log file using a text editor. This log file is stored in the runners' working directory, in a subdirectory named using the runners' UUID (a 32-character hexadecimal string). Such as:

    1 <runner_working_directory>/<runnerUuid>/runner.log

    例:

    1 ~/atlassian-bitbucket-pipelines-runner/temp/b609961f-891e-c872-c36b-f3f2c315d186/runner.log

    The default working directory for the runner is the /temp subdirectory of the atlassian-bitbucket-pipelines-runner directory.

  4. ログ ファイルの最後で対処が必要なエラーを確認します。

ファイルまたはフォルダーの権限を macOS で修正する

In a terminal; fix the permissions on a single file by adding write permissions for the user (u) and the users' user group (g) with the chmod command. Such as:

1 chmod ug+w <path/filename>

To fix the permissions on a directory and its files and subdirectories, add the --recursive option, such as:

1 chmod ug+w --recursive <path/filename>

The chmod command can also be appended to the script of a pipeline step if the permissions issue occurs with every pipeline executed. For example:

1 2 3 4 5 6 7 image: atlassian/default-image:3 pipelines: default: - step: name: 'Step that causes permissions issues' script: - bash ./product-build-script.sh && chmod ug+w --recursive build/

ランナーの設定時に表示されたコマンドを再実行してランナーを再起動するか、ランナーを Bitbucket で再作成します。ランナーのセットアップについては「macOS 用ランナーをセットアップする」をご参照ください。

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

Windows PowerShell にある未署名のスクリプト

Issue

A Windows-based runner has failed to run one or more steps due to an unsigned PowerShell (.ps1) script, resulting in an error similar to the following:

1 2 3 4 5 6 7 8 9 .\start.ps1 : File C:\Users\Administrator\atlassian-bitbucket-pipelines-runner\bin\start.ps1 cannot be loaded. The file C:\Users\Administrator\atlassian-bitbucket-pipelines-runner\bin\start.ps1 is not digitally signed. You cannot run this script on the current system. For more information about running scripts and setting execution policy, see about_Execution_Policies at https:/go.microsoft.com/fwlink/?LinkID=135170. At line:1 char:1 + .\start.ps1 -accountUuid '{924bbdf1-ea18-2c70-4655-2bb23075ddbf}' -re ... + ~~~~~~~~~~~ + CategoryInfo : SecurityError: (:) [], PSSecurityException + FullyQualifiedErrorId : UnauthorizedAccess

原因

The Windows runner generates PowerShell scripts for cloning the repository and running the script for each step in the pipeline. These scripts are generated when the pipeline is run, preventing them from being digitally signed.

To allow the Windows runners to run unsigned PowerShell scripts, set the PowerShell execution policy of the CurrentUser to either:

  • RemoteSigned (recommended)

  • unrestricted

  • bypass

The RemoteSigned execution policy allows local unsigned (uncertified) scripts to run on the device. This includes any potentially malicious unsigned scripts. Before changing the execution policy, review the execution policies and consider their security implications at Microsoft Docs — PowerShell execution policies.

ソリューション

To check the execution policy for the CurrentUser:

  1. Windows の [スタート] メニューから Windows PowerShell を開きます。

  2. Run the following command, which will return the execution policy for the CurrentUser:

    1 Get-ExecutionPolicy -Scope CurrentUser

To change the execution policy for CurrentUser to RemoteSigned:

  1. Windows PowerShell で、次のコマンドを実行します。

    1 Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser
  2. Verify that the change was successful by running Get-ExecutionPolicy and confirm that the CurrentUser has the RemoteSigned execution policy.

    1 Get-ExecutionPolicy -Scope CurrentUser

Microsoft PowerShell 実行ポリシーの詳細については「Microsoft Docs - PowerShell: 実行ポリシーについて」をご参照ください

ビルド フォルダーが適切にクリーンアップされない

ランナーはステップの最後に、ビルド フォルダーのクリーンアップを試みます。これはベスト エフォート型のクリーンアップであり、場合によってはランナーがビルド フォルダーをクリーンアップできない可能性があります。次は、ランナーがビルド フォルダーをクリーンアップするのを妨げる 2 つの最も一般的なケースです。

  • The step script creates files that runners do not have permission to remove, for example, set FullControl as Deny for all users.

  • The step script is creating orphaned processes that a runner is not able to stop, and some of the files in the build are locked by those orphaned processes. For example, a hosted machine had Gradle daemon (which is not suggested by Gradle), and is set to use daemon for all Gradle builds by: org.gradle.daemon=true. In this case, the processes created by Gradle builds will attach to the existing daemon process, and the runner would not able to stop them at the end of the step.

上記のいずれの場合も、ランナーがビルド フォルダーをクリーンアップできなくなります。さらに、ランナー ログを確認してホスト マシンにあるビルド フォルダーを手動でクリーンアップするように指示するエラーが発生して、ステップが失敗します。このランナーで実行するようにスケジュールされているその後のステップもビルド フォルダーが正しくクリーンアップされていないため、エラーが発生します。

解決策: ランナーにアクセスできる管理者に連絡してランナー ログをチェックし、ランナーがビルド フォルダーをクリーンアップできないファイルを特定する必要があります。

ランナーが削除できない権限を持つファイルの場合は、管理者がそれらのファイルの権限を修正してビルド フォルダーを削除し、ランナーを再起動する必要があります。

孤立したプロセスによってロックされているファイルの場合は、管理者がファイルをロックしたプロセスを見つけてそのプロセスを強制終了する必要があります。次に、ビルド フォルダーを削除してランナーを再起動します。

For either of the above solutions, you need to revisit the step script and the current settings for the host machine which will ensure the step won’t lock the build folder next time you run the step, or you will have to do the manual clean up in host machine again. In the case of Gradle daemon, you can add the --no-daemon option in the Gradle build, and it will prevent any child processes attached to the Gradle daemon.

その他のヘルプ