Troubleshooting Server Installations

This document describes an initial set of troubleshooting steps to take if you are having problems with your CircleCI installation on your private server. If your issue is not addressed below, you can generate a support bundle and contact CircleCI Support Engineers by opening a support ticket.

Generating a Support Bundle

To download a support bundle, select Support from the Management Console menu bar, and then select Download Support Bundle. CircleCI support engineers will often request support bundles to help diagnose/fix the problem you are experiencing.

Debug Queuing Builds

If your Services component is fine, but builds are not running, or all builds are queueing, follow the steps below.

1. Check Dispatcher Logs for Errors

sudo docker logs dispatcher を実行します。ログ出力にエラーがなければ、次のステップに進んでください。

If the logs dispatcher container does not exist or is down, start it by running the sudo docker start <container_name> command and monitor the progress. 以下の出力では、ログディスパッチャが起動し、正しく実行されていることがわかります。

Jan 4 22:38:38.589:+0000 INFO circle.backend.build.run-queue dispatcher mode is on - no need for

 run-queue
Jan 4 22:38:38.589:+0000 INFO circle.backend.build.usage-queue 5a4ea0047d560d00011682dc:

 GERey/realitycheck/37 -> forwarded to run-queue
Jan 4 22:38:38.589:+0000 INFO circle.backend.build.usage-queue 5a4ea0047d560d00011682dc: publishing

 :usage-changed (:recur) event

Jan 4 22:38:39.069:+0000 INFO circle.backend.build.usage-queue got usage-queue event for

 5a4ea0047d560d00011682dc (finished-build)

If you see errors or do not see the above output, investigate the stack traces because they indicate that there is an issue with routing builds from 1.0 to 2.0. If there are errors in the output, then you may have a problem with routing builds to 1.0 or 2.0 builds.

1.0 ビルドは実行できるが、2.0 ビルドは実行できない場合、または 2.0 ビルドのみを実行でき、ログディスパッチャが実行されている場合は、次のステップに進んでください。

2. Check Picard-Dispatcher Logs for Errors

sudo docker logs picard-dispatcher コマンドを実行します。 A healthy picard-dispatcher should output the following:

Jan 9 19:32:33 INFO picard-dispatcher.init Still running...
Jan 9 19:34:33 INFO picard-dispatcher.init Still running...
Jan 9 19:34:44 INFO picard-dispatcher.core taking build=GERey/realitycheck/38
Jan 9 19:34:45 INFO circle.http.builds project GERey/realitycheck at revision

2c6179654541ee3d succcessfully fetched and parsed .circleci/config.yml

picard-dispatcher.tasks build GERey/realitycheck/38 is using resource

class {:cpu 2.0, :ram 4096, :class :medium}
picard-dispatcher.tasks Computed tasks for build=GERey/realitycheck/38,

 stage=:write_artifacts, parallel=1
Jan 9 19:34:45 INFO picard-dispatcher.tasks build has matching jobs:

 build=GERey/realitycheck/38 parsed=:write_artifacts passed=:write_artifacts

出力は、上記のメッセージで埋まっているはずです。 処理量が少なく、ほとんどビルドが行われていない日には、以下のように出力されます。

Jan 9 19:32:33.629:+0000 INFO picard-dispatcher.init Still running...

ビルドを実行すると、上記のメッセージが直ちに表示され、スケジューラにディスパッチされたことが確認できます。 If you do not see the above output or you have a stack trace in the picard-dispatcher container, contact support@circleci.com.

2.0 ビルドを実行して、picard-dispatcher ログ出力にメッセージが表示されない場合は、たいていディスパッチャと picard-dispatcher の間でジョブが失われています。

Stop and restart the CircleCI app in the Management Console at port 8800 to re-establish the connection between the two containers.

3. Check Picard-Scheduler Logs for Errors

sudo docker logs picard-scheduler を実行します。 picard-scheduler はジョブをスケジュールし、直接接続によってジョブを Nomad に送信します。 これを行っても、実際に CircleCI 内のジョブのキューイングが処理されるわけではありません。

4. Check Nomad Node Status

nomad node-status -allocs コマンドを実行し、以下のような出力を表示させて、Nomad ノードが存在するかどうかを確認します。

ID        DC         Name             Class        Drain  Status  Running Allocs
ec2727c5  us-east-1  ip-127-0-0-1     linux-64bit  false  ready   0

If you do not see any nomad clients listed, please consult our <nomad#,Introduction to Nomad Cluster Operation> for more detailed information on managing and troubleshooting the nomad server.

DC in the output stands for datacenter and will always print us-east-1 and should be left as such. It doesn’t affect or break anything. ここで重要なのは、Drain、Status、Allocs の各列の内容です。
  • Drain - If Drain is true then CircleCI will not route jobs to that nomad client. It is possible to change this value by running the following command nomad node-drain [options] <node>. Drain を true に設定すると、現在実行中のジョブが終了し、ビルドの受け付けが停止します。 割り当ての数が 0 になれば、インスタンスを停止しても安全です。 Drainfalse に設定すると、ノードが接続を受け付けて、ビルドを取得するようになります。

  • Status - If Status is ready then it is ready to accept builds and should be wired up correctly. 正しく接続されていなければ、ready とは表示されません。Status に ready と表示されないノードはビルドを受け付けないため、調査する必要があります。

  • Allocs - Allocs is a term used to refer to builds. つまり、Running Allocs の数は、単一ノード上で実行されているビルドの数と対応しています。 This number indicates whether builds are routing. すべての Builder に Running Allocs があるにもかかわらず、ジョブがキューイングされる場合は、容量が十分でないため、フリートに Builder を追加する必要があります。

上記のような出力が表示され、それでもビルドがキューイングされている場合は、以下のステップに進んでください。

5. Check Job Processing Status

sudo docker exec -it nomad nomad status コマンドを実行して、現在処理中のジョブを表示させます。 以下のように、各ジョブの ID とステータスが表示されます。

ID                                                      Type   Priority  Status
5a4ea06b7d560d000116830f-0-build-GERey-realitycheck-1   batch  50        dead
5a4ea0c9fa4f8c0001b6401b-0-build-GERey-realitycheck-2   batch  50        dead
5a4ea0cafa4f8c0001b6401c-0-build-GERey-realitycheck-3   batch  50        dead

ジョブが完了すると、Status に dead と表示されます。 これは、ジョブの通常の状態です。 Status に running と表示される場合、ジョブは現在実行中です。 これは、CircleCI アプリケーションのビルドダッシュボードにも表示されます。 アプリケーションに表示されない場合は、output-processor に問題があります。 docker logs picard-output-processor コマンドを実行し、ログに明白なスタックトレースがないかを確認してください。

  • 割り当てが行われず、ジョブが常に pending 状態の場合は、sudo docker exec -it nomad nomad status JOB_ID コマンドを実行します。その結果から、どこで Nomad がスタックしているかが特定できたら、標準的な Nomad Cluster エラーのドキュメントを参照して詳細情報を調べてください。

  • ジョブが実行中または完了しているのに CircleCI アプリケーションに何も表示されない場合は、以下のように対処してください。

    • sudo docker exec -it nomad nomad logs --stderr --job JOB_ID コマンドを実行して、Nomad ジョブのログをチェックします。

    • picard-output-processor コマンドを実行して、ログに特定のエラーがないかどうかをチェックします。

The use of --stderr is to print the specific error if one exists.

Why do my Jobs stay in queued status until they fail and never successfully run?

If the nomad client logs contain the following error message typw, check port 8585:

{"error":"rpc error: code = Unavailable desc = grpc: the connection is
unavailable","level":"warning","msg":"error fetching config, retrying","time":"2018-04-17T18:47:01Z"}

Why is the cache failing to unpack?

If a restore_cache step is failing for one of your jobs, it is worth checking the size of the cache - you can view the cache size from the CircleCI Jobs page within the restore_cache step. We recommend keeping cache sizes under 500MB – this is our upper limit for corruption checks because above this limit check times would be excessively long. キャッシュ サイズを増やすこともできますが、キャッシュの復元中に問題が発生したり、ダウンロード中に破損する可能性が高くなるため、お勧めできません。 キャッシュ サイズを抑えるため、複数のキャッシュに分割することを検討してください。

How do I get around the API service being impacted by a high thread count?

Disable cache warming by completing the following steps:

  1. Add the export DOMAIN_SERVICE_REFRESH_USERS=false flag to the `/etc/circleconfig/api-service/customizations file on the Services machine. For more information on configuration overrides, see the guide to Service Configuration Overrides.

  2. Restart CircleCI:

    1. Navigate to the Management Console

    2. Click Stop Now and wait for it to stop

    3. Click Start



Help make this document better

This guide, as well as the rest of our docs, are open-source and available on GitHub. We welcome your contributions.