I have 11 containers under docker, and they all run with “–restart=always”. So when docker-daemon service started, all container start automatically at once.
One day after os reboot, the os stucked while starting docker-daemon. Now I disable docker-daemon service started and the os work fine.
To solve the problem below:
How can I disable the container start automatically when docker-daemon not started? modify the container config file to disable? where is the config file location? (docker-daemon start first will make os stucked again)
Or is there a way to start docker-daemon on “safe-mode” (like windows safe-mode) and all container don’t started automatically?
The docker daemon (=docker engine) starts containers with --restart=always. If the docker engine is not running, no container can/will be started.
By any chance, did you create systemd units to control containers (some people for whatever reason do)? Or any other mechanism that is automatically started during system initialization?
Thank you for sharing what helped you, although I have to say that the article on the DEV community site is too short to make people understand what the recommended commands do and it is also simply wrong.
docker-compose down
# or "docker compose down" in compose v2
doesn’t just stop containers in a compose project, but removes them. It shouldn’t be a problem but it is also very important to know that it is removing and not stoping as you could lose data too. People who want to find out what starts containers automatically usually beginners and it is more likely that they stored data on the containers filesystem.
The docker update command doesn’t care about config files and scripts. It would change the restart policy of the runnig container, but it doesn’t mean that something or a colleague will not rerun the compose project or the script to change the restart policy back.
The correct way is always to understand what restarts the container and why that container was created that way and change the configuration in the source. Some users had an orchestrator that recreated the containers even if they deleted it, so just running compose down would not solve that either.