AWS batch documentation change
Summary
Fixed maxTimeSeconds example value (144000 → 14400) and removed redundant service role warning
Security assessment
Numerical correction aligns with 4-hour timeout example. Removal of 'service role issue' reference appears to be editorial cleanup rather than security remediation. No explicit security context or vulnerability addressed.
Diff
diff --git a/batch/latest/userguide/job_stuck_in_runnable.md b/batch/latest/userguide/job_stuck_in_runnable.md index 553760bad..6160360f6 100644 --- a//batch/latest/userguide/job_stuck_in_runnable.md +++ b//batch/latest/userguide/job_stuck_in_runnable.md @@ -21 +21 @@ When a job has been in a `RUNNABLE` state with the defined `statusReason`, AWS B -For example, you can set the `jobStateTimeLimitActions` parameter to wait up to 4 hours for any job in the `RUNNABLE` state that is waiting for sufficient capacity to become available. You can do this by setting `statusReason` to `CAPACITY:INSUFFICIENT_INSTANCE_CAPACITY` and `maxTimeSeconds` to 144000 before cancelling the job and allowing the next job to advance to the head of the job queue. +For example, you can set the `jobStateTimeLimitActions` parameter to wait up to 4 hours for any job in the `RUNNABLE` state that is waiting for sufficient capacity to become available. You can do this by setting `statusReason` to `CAPACITY:INSUFFICIENT_INSTANCE_CAPACITY` and `maxTimeSeconds` to 14400 before cancelling the job and allowing the next job to advance to the head of the job queue. @@ -25 +25 @@ The following are the reasons that AWS Batch provides when it detects that a job - 1. **Reason:** All connected compute environments have insufficient capacity errors. When requested, AWS Batch detects Amazon EC2 instances that experience insufficient capacity errors. Manually canceling the job will allow the subsequent job to move to the head of the queue but without resolving the service role issue(s), it is likely that the next job will also be blocked as well. It's best to manually investigate and resolve this issue. + 1. **Reason:** All connected compute environments have insufficient capacity errors. When requested, AWS Batch detects Amazon EC2 instances that experience insufficient capacity errors. Manually canceling the job will allow the subsequent job to move to the head of the queue.