I have a docker service/image I'm using which restarts as soon as starts.
I'm unable to fix the issue by getting into the container using
docker exec -it CONTAIER_NAME
since it restarts/terminates as soon as it boots.
Is there anyway I can pause it directly? I can't rebuild the image as I don't have access to the internet on the server. (Yes I'm sure the rebuild or build--no-cache will fix the issue)
The issue should be easily fixable if I modify permissions for a certain folder, but I'm not sure how to do this inside the container when I can't access it. The image doesn't have a docker file and is used directly from the docker hub.
If we do not get any information from the container's logs, we have the option to start the process "manually". For this, we start the container with an interactive terminal (-it, -i to keep STDIN open, -t to open a pseudo-TTY) and override the entrypoint to be a shell, e.g. bash. For good measure, we want the container to be removed when it terminates (i.e. when we exit the termainal, --rm):
docker run ... -it --rm --entrypoint /bin/bash
Once inside the container, we can start the process that would have normally started through the entrypoint from the container's terminal and extract error information from here.
Related
I created Dockerfile with the following content,
FROM node:16.4.2-alpine3.14
WORKDIR /app
COPY package.json .
COPY . /app
then I created image,
docker build -t app:0.1 .
and then started the container by running,
docker run -it app:0.1
It opened the node shell.
I then closed it.
Doing docker ps -a gives the following output,
Now,
I want to restart the same container and with node shell. How can it be done?
It shows as exited since there is no process running. To start it again , you can use the docker start command with -i flag.
https://docs.docker.com/engine/reference/commandline/start/ for more options
docker rm the existing container and docker run a new one. Consider using the docker run --rm option so the container deletes itself when it's done.
There's nothing special or valuable about a container; it's just a wrapper around a single process (in your case the Node REPL), and creating a new one isn't especially expensive. In the same way that you can't restart the REPL once you've exited it but need to re-run node, you generally will want to delete and recreate containers once their process has finished. With longer-running processes this also helps ensure the process's filesystem is exactly what you expect: if something exits unexpectedly, deleting the container will also remove any temporary files or lock files it's left behind, so restarting the container will run successfully.
use the following sequence of commands:
docker container start magical_merkle
docker attach magical_merkle
Explanation: the first command restarts your exited container, but in detached mode, it means it's running in the background and you can't see it's output. now for you to reattach to the container you run attach command of docker (second command) which attaches the std io of your host terminal to the std io of the running container.
you may notice the magical_merkle in the commands. this is the name of your container as found in the container ls output you provided. when you run the run command, docker will name the container with a auto generated name if you don't provide one for it.
In my CentOS server I use docker created a container,
I opened two sessions connected to the container by command:
docker attach container-name
but there is an issue, in each window I execute command the other window is display the same information.
so I cannot control the container when it is installing package.
is it possible to avoid this issue?
The docker attach command attaches to the currently running process as defined by CMD. You can attach as many times as you want, but they all connect to the same process.
If you want to access the container and have different sessions to it, use:
docker exec -it container-name bash
Or whatever shell is available. bash is common, but you may need to use sh or find out what's used, if any is there at all. Some containers are super stripped down.
The -it flag enables "interactive" mode, as otherwise it just runs that command and shows you the output.
Running docker run with a -d option is described as running the container in the background. This is what most tutorials do when they don't want to interact with the container. On another tutorial I saw the use of bash style & to send the process to the background instead of adding the -d option.
Running docker run -d hello_world only outputs the container ID. On the other hand docker run hello_world & still gives me the same output as if i had run docker run hello_world.
If I do the both experiments with docker run nginx I get the same behavior on both (at least as far as I can see), and both show up if I run docker ps.
Is the process the same in both cases(apart from the printing of the ID and output not being redirected with &)? If not, what is going on behind the scenes in each?
docker is designed as C-S architecture: docker client, docker daemon(In fact still could fined to container-d, shim, runc etc).
When you execute docker run, it will just use docker client to send things to docker daemon, and let daemon call runc etc to start a container.
So:
docker run -d: It will let runc run container in background, you can use docker logs $container_name to see all logs later, the background happend on server side.
docker run &: It will make the linux command run at background, which means the docker run will be in background, this background run on client side. So you still can see stdout etc in terminal. More, if you leave the terminal(even you bash was set as nohup), you will not see it in terminal, you still need docker logs to see them.
Here is my simple docker file
FROM java:8
EXPOSE 4000
now when I run it using the following command
sudo docker run --name hello dockerfile
and do docker ps -a it shows the status as exited. I just want to keep this container up and running so I can ssh into this container and probably transfer files and so on. It looks like containers are mainly used to run servers am I correct?
you can at least keep your container up with something like docker run -d hello sleep infinity but as said by René M, you should put in your Dockerfile something to do in your CMD or ENTRYPOINT, see the doc
https://docs.docker.com/engine/reference/builder/#cmd
and
https://docs.docker.com/engine/reference/builder/#entrypoint
That is realy simple.
Because your container is running nothing that last long. What happens is, that this container starts, has nothing to do and stops.
What you can do is:
Run the container in interactive mode with attached tty. This way your console enters the container after it's start, and let him run a tty, which is something to do and prevends the container from stopping. Then you can work inside this container, like installing an application. Doing this your work will be lost after stoping the container. But you can run docker commit on that container, which makes your changes persistent.
docker run -i -t --name hello dockerfile
Enhance your dockerfile with something usefull. Like copying an application into the container and provide a CMD command to run, when the container starts.
After this the container will last as long as your CMD command runs. If the command is a server or deamon application, the container will last for ever and will only stop when you stop him.
If I use docker exec to fire up a shell,
docker exec -ti <CONTAINER> /bin/bash
I could use Ctrl+p Ctrl+q to detach this shell process. Then this shell is still running inside the container, but how can I reattach to that one particular shell (the one started by docker exec, not docker run)?
Sadly, this is not possible yet; see this issue on GitHub. I've also wanted this functionality, but at the moment it seems like there's no direct way to do this.
A workaround has been proposed, to take care of the case where you're accessing a box via ssh and running docker exec on the remote box (or, for the case where your terminal emulator is unstable and may crash on you): Always run your docker exec commands inside screen or tmux. If you do this, whenever you get detached from the screen/tmux session, you can re-attach to it later and still have your docker exec commands accessible. (this is a bit different than what was suggested by #vodolaz095, since it involves running screen or tmux outside the container, making it suitable for use with containers that don't run screen/tmux as their main process)
docker exec is specifically for running new things in an already started container, be it a shell or some other process.
docker attach is for attaching to a running process, so you can use only one instance of shell.
Run you container(process)
docker run -tid --name <CONTAINER> <IMAGE>:<TAG> bin/bash
Then
docker attach <CONTAINER>
To detach Ctrl+p + Ctrl+q
On this way you can attach and detach multiple times with only one instance of shell