[Bug]: Mongodb/mongodb-atlas-local Randomly Fails To Start
Introduction
This article aims to document and troubleshoot a bug in the mongodb/mongodb-atlas-local container, which randomly fails to start. The issue is observed on both local MacOS and Ubuntu 24.04.2 LTS environments, using the latest Testcontainers.MongoDb version 4.4.0.
Environment Details
Module
- MongoDB
Testcontainers version
- Testcontainers.MongoDb 4.4.0
Using the latest Testcontainers version?
- Yes
Host OS
- Local MacOS
- Ubuntu 24.04.2 LTS (in Github actions)
Host Arch
- M4
Docker version
docker version
Client:
Version: 28.1.1
API version: 1.49
Go version: go1.23.8
Git commit: 4eba377
Built: Fri Apr 18 09:49:45 2025
OS/Arch: darwin/arm64
Context: desktop-linux
Server: Docker Desktop 4.41.2 (191736)
Engine:
Version: 28.1.1
API version: 1.49 (minimum version 1.24)
Go version: go1.23.8
Git commit: 01f442b
Built: Fri Apr 18 09:52:08 2025
OS/Arch: linux/arm64
Experimental: false
containerd:
Version: 1.7.27
GitCommit: 05044ec0a9a75232cad458027ca83437aae3f4da
runc:
Version: 1.2.5
GitCommit: v1.2.5-0-g59923ef
docker-init:
Version: 0.19.0
GitCommit: de40ad0
What happened?
The container starts but doesn't get a "healthy" signal, so it just sits there until it eventually times out.
Relevant log output
The log output from the "hanging" local run on the laptop is provided below:
2025-05-18 17:10:02.217 | {"t":{"$date":"2025-05-18T16:10:02.216+00:00"},"s":"I", "c":"ACCESS", "id":5286306, "ctx":"conn22","msg":"Successfully authenticated","attr":{"client":"172.17.0.4:50074","isSpeculative":true,"isClusterMember":false,"mechanism":"SCRAM-SHA-256","user":"root","db":"admin","result":0,"metrics":{"conversation_duration":{"micros":3177,"summary":{"0":{"step":1,"step_total":2,"duration_micros":204},"1":{"step":2,"step_total":2,"duration_micros":14}}}},"extraInfo":{}}}
2025-05-18 17:10:02.217 | {"t":{"$date":"2025-05-18T16:10:02.216+00:00"},"s":"I", "c":"NETWORK", "id":6788700, "ctx":"conn22","msg":"Received first command on ingress connection since session start or auth handshake","attr":{"elapsedMillis":0}}
2025-05-18 17:10:02.217 | {"t":{"$date":"2025-05-18T16:10:02.217+00:00"},"s":"I", "c":"-", "id":20883, "ctx":"conn21","msg":"Interrupted operation as its client disconnected","attr":{"opId":54273}}
2025-05-18 17:10:02.217 | {"t":{"$date":"2025-05-18T16:10:02.217+00:00"},"s":"I", "c":"NETWORK", "id":22944, "ctx":"conn22","msg":"Connection ended","attr":{"remote":"172.17.0.4:50074","uuid":{"uuid":{"$uuid":"d99b0ec9-edc4-4003-b4f6-ab350d79e437"}},"connectionId":22,"connectionCount":13}}
2025-05-18 17:10:02.217 | {"t":{"$date":"2025-05-18T16:10:02.217+00:00"},"s":"I", "c":"NETWORK", "id":22944, "ctx":"conn23","msg":"Connection ended","attr":{"remote":"172.17.0.4:50088","uuid":{"uuid":{"$uuid":"a0435af7-f940-4c75-9366-f0aa392944d7"}},"connectionId":23,"connectionCount":12}}
2025-05-18 17:10:02.217 | {"t":{"$date":"2025-05-18T16:10:02.217+00:00"},"s":"I", "c":"NETWORK", "id":22944, "ctx":"conn21","msg":"Connection ended","attr":{"remote":"172.17.0.4:50060","uuid":{"uuid":{"$uuid":"822bf265-8466-487b-9950-307e0b109bad"}},"connectionId":21,"connectionCount":11}}
2025-05-18 17:10:02.217 | {"t":{"$date":"2025-05-18T16:10:02.217+00:00"},"s":"I", "c":"NETWORK", "id":22943, "ctx":"listener","msg":"Connection accepted","attr":{"remote":"127.0.0.1:60578","uuid":{"uuid":{"$uuid":"2ba2e817-1746-476b-8d2b-a0ded70e5669"}},"connectionId":24,"connectionCount":12}}
2025-05-18 17:10:02.218 | {"t":{"$date":"2025-05-18T16:10:02.217+00:00"},"s":"I", "c":"NETWORK", "id":51800, "ctx":"conn24","msg":"client metadata","attr":{"remote":"127.0.0.1:60578","client":"conn24","negotiatedCompressors":[],"doc":{"driver":{"name":"mongo-go-driver","version":"1.17.3"},"os":{"type":"linux","architecture":"arm64"},"platform":"go1.24.0","env":{"container":{"runtime":"docker"}}}}}
2025-05-18 17:10:02.218 | {"t":{"$date":"2025-05-18T16:10:02.218+00:00"},"s":"I", "c":"-", "id":20883, "ctx":"conn24","msg":"Interrupted operation as its client disconnected","attr":{"opId":57345}}
2025-05-18 17:10:02.218 | {"t":{"$date":"2025-05-18T16:10:02.218+00:00"},"s":"I", "c":"NETWORK", "id":22943, "ctx":"listener","msg":"Connection accepted","attr":{"remote":"172.17.0.4:50104","uuid":{"uuid":{"$uuid":"754b3ed5-7e5c-4272-a7b8-14e50d6bab0f"}},"connectionId":25,"connectionCount":13}}
2025-05-18 17:10:02.218 | {"t":{"$date":"2025-05-18T16:10:02.218+00:00"},"s":"I", "c":"NETWORK", "id":22944, "ctx":"conn24","msg":"Connection ended","attr":{"remote":"127.0.0.1:60578","uuid":{"uuid":{"$uuid":"2ba2e817-1746-476b-8d2b-a0ded70e5669"}},"connectionId":24,"connectionCount":12}}
2025-05-18 17:10:02.219 | {"t":{"$date":"2025-05-18T16:10:02.219+00:00"},"s":"I", "c":"NETWORK", "id":51800, "ctx":"conn25","msg":"client metadata","attr":{"remote":"172.17.0.4:50104","client":"conn25","negotiatedCompressors":[],"doc":{"driver":{"name":"mongo-go-driver","version":"1.17.3"},"os":{"type":"linux","architecture":"arm64"},"platform":"go1.24.0","env":{"container":{"runtime":"docker"}}}}}
2025-05-18 17:10:02.219 | {"t":{"$date":"2025-05-18T16:10:02.219+00:00"},"s":"I", "c":"NETWORK", "id":22943, "ctx":"listener","msg":"Connection accepted","attr":{"remote":"172.17.0.4:50120","uuid":{"uuid":{"$uuid":"81ab6d75-4c<br/>
**Q&A: mongodb/mongodb-atlas-local randomly fails to start**
**Q: What is the issue with the mongodb/mongodb-atlas-local container?**
A: The container starts but doesn't get a "healthy" signal, so it just sits there until it eventually times out.
**Q: What is the environment where the issue is observed?**
A: The issue is observed on both local MacOS and Ubuntu 24.04.2 LTS environments, using the latest `Testcontainers.MongoDb` version 4.4.0.
**Q: What is the Docker version being used?**
A: The Docker version being used is 28.1.1.
**Q: What is the log output from the "hanging" local run on the laptop?**
A: The log output from the "hanging" local run on the laptop is provided above.
**Q: What is the frequency of the failure?**
A: The failure happens randomly but it happens quite a lot. As a gut feeling, I'd say about 40-50% of the time.
**Q: How to recover from the failure?**
A: The only way to recover is to stop the execution and start again.
**Q: What are the possible causes of the issue?**
A: The possible causes of the issue are:
* **Insufficient resources**: The container may not have enough resources (e.g. CPU, memory) to run properly.
* **Network issues**: There may be network issues that prevent the container from communicating with the outside world.
* **Container configuration**: The container configuration may be incorrect, leading to the issue.
* **Docker version**: The Docker version being used may be causing the issue.
**Q: How to troubleshoot the issue?**
A: To troubleshoot the issue, you can try the following:
* **Check the logs**: Check the logs of the container to see if there are any error messages.
* **Check the resources**: Check if the container has enough resources (e.g. CPU, memory) to run properly.
* **Check the network**: Check if there are any network issues that may be preventing the container from communicating with the outside world.
* **Check the container configuration**: Check if the container configuration is correct.
* **Try a different Docker version**: Try using a different Docker version to see if the issue persists.
**Q: How to prevent the issue from happening in the future?**
A: To prevent the issue from happening in the future, you can try the following:
* **Increase the resources**: Increase the resources (e.g. CPU, memory) allocated to the container.
* **Improve the network**: Improve the network configuration to prevent any network issues.
* **Check the container configuration**: Regularly check the container configuration to ensure it is correct.
* **Use a different Docker version**: Use a different Docker version to see if the issue persists.
* **Monitor the logs**: Regularly monitor the logs of the container to catch any issues early.