Skip to content

DOC-404: Document orphaned containers after Docker Compose stop #894

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
quetzalliwrites wants to merge 1 commit into
base: main
Choose a base branch
from
Open

DOC-404: Document orphaned containers after Docker Compose stop #894

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
21 changes: 21 additions & 0 deletions src/content/docs/aws/getting-started/faq.mdx
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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.
Expand Down
4 changes: 4 additions & 0 deletions src/content/docs/aws/services/eks.mdx
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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:
Expand Down
Loading