翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。 # `RUNNABLE` 状態でジョブが止まる コンピューティング環境にコンピューティングリソースがあるのに、ジョブが `RUNNABLE` の状態よりも先に進まないとします。その場合、ジョブがコンピューティングリソースに配置されるのが何かの原因で妨げられ、ジョブキューがブロックされている可能性があります。ここでは、ジョブが順番を待っているのか、スタックしてキューをブロックしているのか確認する方法を説明します。 が先頭に`RUNNABLE`ジョブがあり、キューをブロックしていること AWS Batch を検出すると、Amazon CloudWatch Events から理由を含む[ジョブキューのブロックイベント](batch-job-queue-blocked-events.md)イベントを受け取ります。同じ理由が、`[ListJobs](https://docs.aws.amazon.com/batch/latest/APIReference/API_ListJobs.html)` と `[DescribeJobs](https://docs.aws.amazon.com/batch/latest/APIReference/API_DescribeJobs.html)` の API コールの一部として `statusReason` フィールドに挿入されます。 必要に応じて、`[CreateJobQueue](https://docs.aws.amazon.com/batch/latest/APIReference/API_CreateJobQueue.html)` と [https://docs.aws.amazon.com/batch/latest/APIReference/API_UpdateJobQueue.html](https://docs.aws.amazon.com/batch/latest/APIReference/API_UpdateJobQueue.html) の API アクションを使用して `jobStateTimeLimitActions` パラメータを設定できます。 **注記** 現在、Amazon ECS、Amazon EKS、または Fargate コンピューティング環境に接続されているジョブキューの場合、 で使用できる唯一のアクション`jobStateLimitActions.action`はジョブをキャンセルすることです。 `jobStateTimeLimitActions` パラメータは、特定の状態のジョブに対して が AWS Batch 実行する一連のアクションを指定するために使用されます。`maxTimeSeconds` フィールドを使用して時間のしきい値を秒単位で設定できます。 ジョブが定義された `RUNNABLE`の状態にある場合`statusReason`、 `maxTimeSeconds` は経過後に指定されたアクションを実行 AWS Batch します。 例えば、`jobStateTimeLimitActions` パラメータを使用すると、ジョブが十分な容量を利用できるようになるまで、`RUNNABLE` 状態で最大 4 時間待機するように設定できます。これを行うには、ジョブをキャンセルする前に `CAPACITY:INSUFFICIENT_INSTANCE_CAPACITY`と `maxTimeSeconds`を 14400 `statusReason`に設定し、次のジョブをジョブキューの先頭に進めます。 以下は、ジョブキューがブロックされていることを が検出 AWS Batch したときに が提供する理由です。このリストでは `ListJobs` と `DescribeJobs` の API アクションから返されるメッセージを示しています。また、これらは `jobStateLimitActions.statusReason` パラメータに定義できる値と同じです。 1. **理由: ** 接続されているすべてのコンピューティング環境で、容量不足のエラーが出ています。リクエストされると、 は容量不足エラーが発生した Amazon EC2 インスタンス AWS Batch を検出します。ジョブを手動でキャンセルすると、後続のジョブがキューの先頭に移動できるようになります。 + **ジョブがスタックしているときの `statusReason` メッセージ: **`CAPACITY:INSUFFICIENT_INSTANCE_CAPACITY - Service cannot fulfill the capacity requested for instance type [instanceTypeName]` + **`jobStateTimeLimitActions` に使用される `reason`: **`CAPACITY:INSUFFICIENT_INSTANCE_CAPACITY` + **ジョブがキャンセルされた後の `statusReason` メッセージ: **`Canceled by JobStateTimeLimit action due to reason: CAPACITY:INSUFFICIENT_INSTANCE_CAPACITY` **メモ:** 1. AWS Batch サービスロールには、この検出が機能するための`autoscaling:DescribeScalingActivities`アクセス許可が必要です。[のサービスにリンクされたロールの使用 AWS Batch](using-service-linked-roles.md) のサービスにリンクされたロール (SLR) または [AWS マネージドポリシー: **AWSBatchServiceRole** ポリシー](security-iam-awsmanpol.md#security-iam-awsmanpol-AWSBatchServiceRolePolicy) の管理ポリシーを使用する場合、アクセス許可ポリシーが更新されるためアクションは必要ありません。 1. SLR または管理ポリシーを使用する場合は、`autoscaling:DescribeScalingActivities` と `ec2:DescribeSpotFleetRequestHistory` のアクセス許可を追加して、`RUNNABLE` のときにブロックされたジョブキューイベントと更新されたジョブステータスを受信できるようにする必要があります。さらに、 AWS Batch では、ジョブキューで設定されていても `jobStateTimeLimitActions` パラメータを使用して `cancellation` アクションを実行するため、これらのアクセス許可が必要です。 1. マルチノード並列 (MNP) ジョブの場合、アタッチされた高優先度の Amazon EC2 コンピューティング環境で `insufficient capacity` エラーが発生すると、優先度の低いコンピューティング環境でこのエラーが発生してもキューがブロックされます。 1. **理由: **すべてのコンピューティング環境に、ジョブ要件よりも小さい [https://docs.aws.amazon.com/batch/latest/APIReference/API_ComputeResource.html#Batch-Type-ComputeResource-maxvCpus](https://docs.aws.amazon.com/batch/latest/APIReference/API_ComputeResource.html#Batch-Type-ComputeResource-maxvCpus) パラメータがあります。手動でジョブをキャンセルするか、`statusReason` に `jobStateTimeLimitActions` パラメータを設定してキャンセルすると、後続のジョブがキューの先頭に移動できるようになります。必要に応じて、プライマリコンピューティング環境の `maxvCpus` パラメータを増やして、ブロックされたジョブのニーズを満たすことができます。 + **ジョブがスタックしているときの `statusReason` メッセージ: **`MISCONFIGURATION:COMPUTE_ENVIRONMENT_MAX_RESOURCE - CE(s) associated with the job queue cannot meet the CPU requirement of the job.` + **`jobStateTimeLimitActions` に使用される `reason`: **`MISCONFIGURATION:COMPUTE_ENVIRONMENT_MAX_RESOURCE` + **ジョブがキャンセルされた後の `statusReason` メッセージ: **`Canceled by JobStateTimeLimit action due to reason: MISCONFIGURATION:COMPUTE_ENVIRONMENT_MAX_RESOURCE` 1. **理由: **ジョブの要件を満たすインスタンスが、どのコンピューティング環境にもありません。ジョブがリソースをリクエストすると、 はアタッチされたコンピューティング環境が受信ジョブに対応できないことを AWS Batch 検出します。手動でジョブをキャンセルするか、`statusReason` に `jobStateTimeLimitActions` パラメータを設定してキャンセルすると、後続のジョブがキューの先頭に移動できるようになります。必要に応じて、コンピューティング環境で許可されるインスタンスタイプを再定義して、必要なジョブリソースを追加できます。 + **ジョブがスタックしているときの `statusReason` メッセージ: **` MISCONFIGURATION:JOB_RESOURCE_REQUIREMENT - The job resource requirement (vCPU/memory/GPU) is higher than that can be met by the CE(s) attached to the job queue.` + **`jobStateTimeLimitActions` に使用される `reason`: **`MISCONFIGURATION:JOB_RESOURCE_REQUIREMENT` + **ジョブがキャンセルされた後の `statusReason` メッセージ: **`Canceled by JobStateTimeLimit action due to reason: MISCONFIGURATION:JOB_RESOURCE_REQUIREMENT` 1. **理由: ** すべてのコンピューティング環境にサービスロールの問題があります。これを解決するには、サービスロールのアクセス許可を [AWS の 管理ポリシー AWS Batch](security-iam-awsmanpol.md) と比較して、ギャップがあれば対処します。注意: このエラーを解決するために、`jobStateTimeLimitActions` パラメータを使用してプログラム可能なアクションを設定することはできません。 同様のエラーを避けるため、[のサービスにリンクされたロールの使用 AWS Batch](using-service-linked-roles.md) を使用するのがベストプラクティスです。 手動でジョブをキャンセルするか、`statusReason` に `jobStateTimeLimitActions` パラメータを設定してキャンセルすると、後続のジョブがキューの先頭に移動できるようになります。サービスロールの問題をすべて解決しないと、次のジョブもブロックされる可能性があります。この問題は手動で調査して解決することをお勧めします。 + ** ジョブがスタックしているときの `statusReason` メッセージ: **`MISCONFIGURATION:SERVICE_ROLE_PERMISSIONS – Batch service role has a permission issue.` 1. **理由:** コンピューティング環境にサポートされていないインスタンスタイプの設定があります。これは、選択したアベイラビリティーゾーンでインスタンスタイプが使用できない場合、または起動テンプレートまたは起動設定に指定されたインスタンスタイプと互換性のない設定が含まれている場合に発生する可能性があります。これを解決するには、指定した AWS リージョン およびアベイラビリティーゾーンでインスタンスタイプがサポートされていること、起動テンプレート設定がインスタンスタイプと互換性があることを確認し、新しい世代のインスタンスタイプへの更新を検討してください。サポートされているインスタンスタイプの検索の詳細については、「*Amazon EC2 ユーザーガイド*」の「[Amazon EC2 インスタンスタイプの検索](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-discovery.html)」を参照してください。 + ** ジョブがスタックしているときの `statusReason` メッセージ: **`MISCONFIGURATION:EC2_INSTANCE_CONFIGURATION_UNSUPPORTED - Your compute environment associated with this job queue has an unsupported instance type configuration.` 1. **理由: **すべてのコンピューティング環境が無効です。詳細については、「[`INVALID` コンピューティング環境](invalid_compute_environment.md)」を参照してください。注意: このエラーを解決するために、`jobStateTimeLimitActions` パラメータを使用してプログラム可能なアクションを設定することはできません。 + **ジョブがスタックしているときの `statusReason` メッセージ: **`ACTION_REQUIRED - CE(s) associated with the job queue are invalid.` 1. **理由:** AWS Batch がブロックされたキューを検出しましたが、理由を判断できません。注意: このエラーを解決するために、`jobStateTimeLimitActions` パラメータを使用してプログラム可能なアクションを設定することはできません。トラブルシューティングの詳細については、*re:Post* の「[AWSAWS Batch ジョブが [RUNNABLE] ステータスでスタックしているのはなぜですか?](https://repost.aws/knowledge-center/batch-job-stuck-runnable-status)」を参照してください。 + **ジョブがスタックしているときの `statusReason` メッセージ: **`UNDETERMINED - Batch job is blocked, root cause is undetermined.` CloudWatch Events からイベントを受信しなかった場合、または原因不明のイベントを受信した場合、一般に以下のようないくつかの原因が考えられます。 **`awslogs` のログドライバーが、コンピューティングリソースで設定されていない** AWS Batch ジョブはログ情報を CloudWatch Logs に送信します。この機能を有効にするには、`awslogs`のログドライバーを使用するようにコンピューティングリソースを設定する必要があります。コンピューティングリソース AMI を、Amazon ECSに最適化されたAMI (または Amazon Linux) に基づいて作成すると仮定します。次に、このドライバーはデフォルトにより `ecs-init`のパッケージに登録されます。ここで、別のベース AMI を使用すると仮定します。別の基本 AMI を使用する場合、Amazon ECS コンテナエージェントが開始するときに、`awslogs` ログドライバーが、 `ECS_AVAILABLE_LOGGING_DRIVERS` 環境変数で使用可能なログドライバーとして指定されていることを検証する必要があります。詳細については、[コンピューティングリソースの AMI 仕様](batch-ami-spec.md) および[チュートリアル: コンピューティングリソース AMI を作成する](create-batch-ami.md)を参照してください。 **リソースが不十分である** コンピューティングリソースが割り当てることができるリソースを超えた CPU、またはメモリリソースがジョブ定義に指定されている場合、ジョブは配置されません。例えば、ジョブが 4 GiB のメモリを指定し、コンピューティングリソースで使用できるのがそれ以下の場合を考えます。そうなると、そのジョブをそれらのコンピューティングリソースに配置できない場合があります。この場合、ジョブ定義に指定するメモリを減らすか、あるいは環境のコンピューティングリソースを追加する必要があります。一部のメモリは、Amazon ECS コンテナエージェントやその他の重要なシステムプロセス用に予約されています。詳細については、[コンピューティングリソースメモリの管理](memory-management.md)を参照してください。 **コンピューティングリソースのインターネットアクセスがない** コンピューティングリソースには、Amazon ECS サービスエンドポイントと通信するために外部ネットワークアクセスが必要です。これは、インターフェイス VPC エンドポイントを介して、またはパブリック IP アドレスを持つコンピュートリソースを通じて可能になります。 インターフェイス VPC エンドポイントの詳細については、*Amazon Elastic Container Service 開発者ガイド*の[Amazon ECS インターフェイス VPC エンドポイント (AWS PrivateLink)](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/vpc-endpoints.html) を参照してください。 インターフェイス VPC エンドポイントが設定されておらず、コンピューティングリソースがパブリック IP アドレスを持たない場合は、ネットワークアドレス変換 (NAT) を使用してこのアクセスを提供する必要があります。詳細については、*Amazon VPC ユーザーガイド*の [NAT ゲートウェイ](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html)を参照してください。詳細については、[VPC を作成する](create-a-vpc.md)を参照してください。 **Amazon EC2 インスタンス制限に達している** アカウントが で起動できる Amazon EC2 インスタンスの数 AWS リージョン は、EC2 インスタンスのクォータによって決まります。特定のインスタンスタイプには、インスタンスタイプごとの制限もあります。ユーザーのアカウントの Amazon EC2 インスタンスクォータの詳細 (制限の引き上げをリクエストする方法を含む) については、「*Amazon EC2 ユーザーガイド*」の「[Amazon EC2 の Service Quotas](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-resource-limits.html)」を参照してください。 **Amazon ECS コンテナエージェントが存在しない** AWS Batch ジョブを実行するには、Amazon ECS コンテナエージェントは Amazon マシンイメージ (AMI) にインストールされる必要があります。Amazon ECS コンテナエージェントが Amazon ECSに最適化 AMI にデフォルトでインストールされます。Amazon ECS コンテナエージェントの詳細については、「*Amazon Elastic Container Service デベロッパーガイド*」の「[Amazon ECS コンテナエージェント](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ECS_agent.html)」を参照してください。 詳細については、*「re:Post*」の[「Why is my AWS Batch job stuck in `RUNNABLE` status?](https://aws.amazon.com/premiumsupport/knowledge-center/batch-job-stuck-runnable-status/)」を参照してください。