I'm encountering an issue with my ECS Fargate Spot task where it's getting killed prematurely. According to the AWS documentation, the task should receive a SIGTERM signal before being forcefully stopped, and there's a stopTimeout that can be set, up to a maximum of 120 seconds. I have configured my task definition with stopTimeout set to 120 seconds:
```json
"containerDefinitions": [
{
"name": "default",
"stopTimeout": 120,
...
}
]
```
However, in practice, my task was killed after only about 21 seconds. I logged the application events, and this is what the timeline shows:
- 18:08:30.619Z: "Received SIGTERM"
- 18:08:51.746Z: Process killed with SIGKILL (exitCode: 137)
The execution details also confirm that my task was interrupted with:
- stopCode: SpotInterruption
- stoppedReason: Your Spot Task was interrupted.
Given this, is it normal for stopTimeout to be disregarded during Spot interruptions? Or could this be a bug?
2 Answers
It sounds like you're on the right track questioning the stopTimeout. When AWS needs resources, they can prioritize that over your custom timeout settings. So, yes, it's quite common for spot interruptions to not honor the configured stopTimeout. Just ensure your app handles SIGTERM properly to avoid abrupt kills and potential data loss!
Actually, the docs are clear that Fargate Spot should give you a heads-up before the task is killed. They mention a two-minute warning for interruptions, but it's crucial that your application is set up to handle the SIGTERM correctly. If it's not processing that signal as expected, it might lead to a forced SIGKILL, which could explain the early termination.
Related Questions
Can't Load PhpMyadmin On After Server Update
Redirect www to non-www in Apache Conf
How To Check If Your SSL Cert Is SHA 1
Windows TrackPad Gestures