Docker Woes: When Containers Refuse to Listen and Databases Play Hard to Get

We can all agree at this point that Docker is a unique tool. The magic of having a consistent environment for both development and production is truly one of a kind.

Despite its many benefits, setting it up can sometimes be a bit of a headache, whether it's for a single container or a network of containers.

In this article, we will look at:

• Why you can't stop/kill your container and why it happens
• Access Denied issues on database containers, even when using the correct username and password

Why can't I stop/kill my Docker container, and why does this happen?

Docker containers can become extremely frustrating when you try Ctrl + C or Cmd + C, and the container does not stop. You might start questioning your life choices, and eventually, you open another terminal to kill it using docker kill, only to receive a Permission denied error, even when running with sudo.

Instead of rebooting your system each time or trying to reset your Docker service, using kill -9 can help. First, find all running services using pgrep docker, then pick the process numbers and use kill -9 <process number> to terminate the process.

Why does this happen?

This issue often occurs because the process running inside the Docker container has a restart policy or operand.

For example, consider the following process:

uvicorn main:app --reload

If you run this app inside a Docker container and let it start by default when the container is launched, you won't be able to kill it because the --reload option continuously restarts the app, even when the SIGINT signal is sent.

Access Denied on database containers, even with the correct username and password

This problem can be puzzling. You might think, "Did I miss a comma, or perhaps there's an extra space?" Maybe you suspect there's an "Egyptian semicolon" in the password. But no, I’m sure of it — I copy-pasted the credentials, so even the Egyptian semicolon should have worked.

The issue occurred while using a docker-compose.yml file. The strange part was that the image ran fine on a single Docker container but failed when used with a docker-compose file. I began removing extra parameters I wasn’t using when running the container individually, and it all came down to one culprit: MYSQL_HOST.

Specifying this parameter caused a myriad of problems, as outlined in the issue here.

Avoiding it is a better way to resolve the problem.