From ef16f22de32af158c740943465e9bf973f22427a Mon Sep 17 00:00:00 2001 From: Quetzalli Date: Tue, 25 Aug 2026 20:55:05 +0200 Subject: [PATCH] DOC-404: Document orphaned containers after Docker Compose stop Add an FAQ entry explaining that Docker Compose's default 10s SIGTERM-to-SIGKILL grace period can be too short for LocalStack to finish tearing down auxiliary containers (including k3d containers backing an EKS cluster), leaving them behind as orphans, and how to raise stop_grace_period to avoid it. The CLI is not affected since it waits for shutdown to finish. Cross-link the same behavior from the EKS docs where k3d-backed cluster creation is introduced. --- src/content/docs/aws/getting-started/faq.mdx | 21 ++++++++++++++++++++ src/content/docs/aws/services/eks.mdx | 4 ++++ 2 files changed, 25 insertions(+) diff --git a/src/content/docs/aws/getting-started/faq.mdx b/src/content/docs/aws/getting-started/faq.mdx index d394245bb..9d6b4aeb4 100644 --- a/src/content/docs/aws/getting-started/faq.mdx +++ b/src/content/docs/aws/getting-started/faq.mdx @@ -154,6 +154,27 @@ For example, a container which attempts to deploy a stack and interact with the Refer to our [network troubleshooting guide](/aws/customization/networking/) covering several scenarios. +### Why are some containers left behind after I stop LocalStack with Docker Compose? + +When LocalStack shuts down, it cleans up the auxiliary containers it started, including k3d containers that back an EKS cluster. + +Docker Compose sends `SIGTERM` to the container and then, after a grace period of 10 seconds, follows up with `SIGKILL`. +That default window might be too short for LocalStack to finish its cleanup in some scenarios, so it is killed mid-teardown and the containers survive as orphans. + +To give LocalStack enough time to shut down cleanly, raise `stop_grace_period` on the LocalStack service in your `docker-compose.yml` (for example, `3m`): + +```yaml +services: + localstack: + image: localstack/localstack-pro:latest + stop_grace_period: 3m + # ... +``` + +If a previous run already left containers behind, remove them before starting LocalStack again. + +This applies to Docker Compose specifically. Starting LocalStack with the CLI is not affected, as the CLI waits for LocalStack to finish shutting down. + ### How to resolve the pull rate limit issue for LocalStack's Docker image? If you receive `ERROR: toomanyrequests: Too Many Requests.` when pulling the LocalStack Docker image, you have reached your pull rate limit. diff --git a/src/content/docs/aws/services/eks.mdx b/src/content/docs/aws/services/eks.mdx index e09fccda5..4e57cd16b 100644 --- a/src/content/docs/aws/services/eks.mdx +++ b/src/content/docs/aws/services/eks.mdx @@ -102,6 +102,10 @@ K3D_START_LB_INGRESS=1 ``` ::: +:::note +If you run LocalStack with Docker Compose, the k3d containers backing an EKS cluster can be left behind as orphans if LocalStack is killed before it finishes shutting down. See [Why are some containers left behind after I stop LocalStack with Docker Compose?](/aws/getting-started/faq/#why-are-some-containers-left-behind-after-i-stop-localstack-with-docker-compose) for the cause and how to configure `stop_grace_period` to avoid it. +::: + You can create a new cluster using the [`CreateCluster` API](https://docs.aws.amazon.com/eks/latest/APIReference/API_CreateCluster.html). Run the following command: