If the graceful shutdown of your docker-compose services takes at least 10 seconds, you might want to investigate whether you might be ignoring signals like SIGTERM.īy avoiding the above pitfalls, you’ll make your experience of interacting with your containers nicer. Handling signals will make your containers respond to the request of being stopped. Handling signals and processes as PID 1 properly has many edge cases, and using a valid init in your containers is a great idea. You should also consider to use an init system inside of your containers - like dumb-init, tini or by using the init: true docker-compose option on newer Docker versions (nothing magical here, tini is used by Docker by default with this option). # Run the "exit" command when receiving SIGNAL
DOCKER DESKTOP IS SHUTTING DOWN HOW TO
If your entrypoint script is running continuously, with a while loop for example, you should tell it how to react to incoming signals before starting to loop. # Run the long-running command in your script with exec: With exec, your process “takes the place” and gets all signals, otherwise they are received and kept by the entrypoint script. # Exec form - GOOD! No "/bin/sh -c" is addedĪnother possible cause, is if you run your process from an entrypoint script without using exec. # Shell form - DANGER! This becomes "/bin/sh -c your_command" Check out this table for an overview how different CMD and ENTRYPOINT formats interact with each other, and watch out for the /bin/sh -c part. That shell process does not pass any signals to your actual command.
If you have defined your ENTRYPOINT (or CMD, you should care about the difference), in shell form instead of exec form, there’s a /bin/sh -c running as PID 1 in your container. This can be caused by multiple small mistakes. Where Are My Signals?Ĭhances are, an unintended shell process has them. The most probable cause, is that your app simply doesn’t get the signals. Not being able to do so should be seen as a bug. Handling signals is quite an important task to be a good process-citizen. With option 3, your dockerized process simply ignores the signal. This is the exception - most apps should react to SIGTERM and SIGINT at least. You can configure the right signal for your dockerized application via the stop_signal or directly in the Dockerfile. Nginx is an example for the second option - it would much rather get a SIGQUIT signal. If that’s the case, your waiting issue won’t be fixed, but is the right thing to do. You can configure this using the docker-compose stop_grace_period. Either by optimizing the app or by extending the timeout.
It will ask them to stop in the right order, waiting for each one. If your containers depend on each other, docker-compose can’t shut them down all at once. If even one of your containers does not respond to SIGTERM signals, Docker will wait for 10 seconds at least. There’s a timeout, which is 10 seconds by default for each container. Well-behaved programs that receive a SIGTERM are supposed to finish anything which is important, don’t take on new work and exit as soon as possible on their own terms.ĭocker has limited patience when it comes to stopping containers. This is a polite way to let a program know that it’s supposed to shut down at its own pace, but do so quickly. It lets them know, by sending a SIGTERM signal to each container. When you tell docker-compose to stop containers with docker-compose down, docker-compose stop, docker-compose restart or just by pressing ctrl+c in the terminal where docker-compose up is running, docker-compose tries to stop your containers as gently as possible. Rather, it’s because of your dockerized apps don’t react to a SIGTERM signal and time out instead. If you need to wait for your containers to be “stopped gracefully”, chances are that docker-compose isn’t at fault. Waiting for containers to stop or when restarting can cost a lot of time if you’re using docker-compose for development. Working with docker-compose can feel like a chore if it makes you wait again and again. The Reason Why You Need to Wait When Stopping Your Docker Compose Services
0 kommentar(er)
