When finished editing another docker cp of the original entrypoint back into the container and a re-restart should do the trick. The running container can now be further edited with the bash shell to correct any problems. This means you can copy the original out of the container, edit a copy of it to start a bash shell (or a long sleep timer) instead of whatever it was doing, and then restart the container.
#DOCKER RESTART CONTAINER FULL#
If the full path to the entrypoint for the container is known (or discoverable via inspection) it can be copied in and out of the stopped container using 'docker cp'. Lots of discussion surrounding this so I thought I would add one more which I did not immediately see listed above: While the container is running, you can also remove already_ran and manually execute the entrypoint.sh script to rerun it, if you need to debug that way. You can then execute a debugging bash session: docker exec -i container_name bash When you restart the container, the already_ran file will be found, causing the Entrypoint script to stall with cat (which just waits forever for input that will never come, but keeps the container alive). You can then restart the container to perform debugging: docker start container_name This will cause the script to run once, creating a file that indicates it has already run (in the container's virtual filesystem). I'm running the container with my Entrypoint script like so: docker run -t -entrypoint entrypoint.sh image_name To ensure that cat holds the connection, you may need to provide a TTY. Then, at the top of this file, add these lines to entrypoint.sh: # Run once, hold otherwiseĮcho "Already ran the Entrypoint once. If you don't already have an Entrypoint script, create one that runs whatever command(s) you need for your container. NOTE2: Newer versions of docker have config.v2.json, where you will need to change either Entrypoint or Cmd (thanks user60561).Īdd a check to the top of your Entrypoint scriptĭocker really needs to implement this as a new feature, but here's another workaround option for situations in which you have an Entrypoint that terminates after success or failure, which can make it difficult to debug. you did not create the original container with -it option), you can instead change the command to "/bin/sleep 600" or "/bin/tail -f /dev/null" to give you enough time to do "docker exec -it CONTID /bin/bash" as another way of getting a shell.
NOTE: If your shell is not interactive (e.g. Start the container and attach to it, you should now be in your shell! docker start -ai mad_brattain List your containers and make sure the command has changed: docker ps -a Restart the docker service (note this will stop all running containers unless you first enable live-restore): service docker restart You may also set the "Args" parameter to pass arguments to the command. Edit this file (corresponding to your stopped container): vi /var/lib/docker/containers/923.4f6/config.jsonĬhange the "Path" parameter to point at your new command, e.g.
0 kommentar(er)
