0

When I exec the commmand, it occur this error

docker run -it --entrypoint=/bin/bash ld_mmdet:2.4.0 /bin/bash

docker: Error response from daemon: oci runtime error: container_linux.go:247: starting container process caused "exec: \"/bin/bash\": stat /bin/bash: no such file or directory".

then I inspect the images, and found the cmd is null, like this

 "ContainerConfig": {
            "Hostname": "",
            "Domainname": "",
            "User": "",
            "AttachStdin": false,
            "AttachStdout": false,
            "AttachStderr": false,
            "Tty": false,
            "OpenStdin": false,
            "StdinOnce": false,
            "Env": null,
            "Cmd": null,
            "Image": "",
            "Volumes": null,
            "WorkingDir": "",
            "Entrypoint": null,
            "OnBuild": null,
            "Labels": null
        },

So, is there any solution to resolve this? I have try the methods as follows:

  • using /bin/sh or /bash instead of /bin bash，NOT WORK
  • using docker run -it --entrypoint=/bin/bash ld_mmdet:2.4.0 /bin/bash，NOT WORK
nwpuxhld
  • 85
  • 1
  • 1
  • 10

1 Answers1

2

First, a good practice is launching docker in detached mode and then access it with docker exec -it, for example.

Second, you need to specify an entrypoint or command that doesn't finish.

All /bin/bash, /bin/sh command finishes unless you add args such as sleep infinity or similar. I recommend you execute tail -F /dev/null and then access docker with your bash or sh.

docker run -d --name mymmdet ld_mmdet:2.4.0 tail -F /dev/null
docker exec -ti mymmdet bash

You can verify after docker run command if your docker is running with docker ps -a, and if it's up, then docker exec.

Alejandro Galera
  • 3,445
  • 3
  • 24
  • 42
  • 1
    Running bash in interactive mode in a terminal (`-it`) does not finish. The problem here (beside the fact that using the same binary as entrypoint and command is odd...) is that bash is not installed inside the image or at least not in the path that OP is using. Solving the issue requires to know what is the base image he is using (wich is why I voted to close for lack of debugging info). – Zeitounator Aug 19 '20 at 09:44
  • 1
    (I don't think there's anything wrong with `docker run --rm -it imagename sh` to get a temporary container with a debugging shell.) – David Maze Aug 19 '20 at 09:45
  • @Zeitounator, I'm not saying that `-it` finishes. `bash` as command or entrypoint does if you launch it detached. – Alejandro Galera Aug 19 '20 at 09:56
  • You don't need to detach in that case if you only want to run bash. And the problem will remain if you detach a never ending command and try to exec a non existing bash on the container later (If it eventually started correctly...). In this case, it only introduces complexity IMO and does not fix OP's problem at all. – Zeitounator Aug 19 '20 at 10:03
  • I know that I don't need it. I told that it's recommended, not needed. That's just a good practice that lets you check if docker is running before you enter in interactive mode, and also prevent shell can sometimes get hanged. – Alejandro Galera Aug 19 '20 at 10:05
  • 2
    I don't agree it is a good practice in all cases. If you only need to run bash or a single command it might even be a bad one. – Zeitounator Aug 19 '20 at 10:06
  • Why would I run a container in detached mode with a long running command such as `tail -f ...` in your example to further exec e.g. (replace with what ever one time command you can imagine in a utility image) `ssh-keygen -f /path/to/my/key` then stop my container when all I need to do is run that command straight ahead that will exit when done ? If OP only needs to run bash to interact with a running container, why would he run a non needed background command first ? I see this as unneeded complexity and bad practice. Moreover, there is absolutely no proof so far this will solve OP's problem. – Zeitounator Aug 19 '20 at 12:26
  • Why? I told you before several advantages :) If you don't like, don't do it, is very simple. I prefer check if container runs, is healthy, check logs and then run into. Normally, when I know a container works, I don't use detached mode, but in this case, `docker run` is what fails. That's why I recommend detached mode. Let me insist. If you prefer not to use it is ok, but I've already explained it's an option, not the only one and why I recommend it in this case. Have a good day – Alejandro Galera Aug 19 '20 at 12:28
  • How does it solves OP's problem? Will checking a log that consist of tailing `/dev/null` help him to find if and where bash is installed ? Have a good day to. – Zeitounator Aug 19 '20 at 12:35
  • I told you. Sometimes, you have to work with a docker image that you don't know if it contains bash, sh, ash or whatever. If you execute `tail -F /dev/null` you get the same than if you start with command overriding `bash -c "sleep infinity"` in ubuntu, for example. It let's you to check many things, and try different ways of entering it interactively preventing a shell hanging. You can also check a crash due to core in healthcheck... there are many advantages depending of your image. You don't know which kind of shell exists but normally tail does. That's for getting clues when `run` crashes – Alejandro Galera Aug 19 '20 at 12:40
  • Finally, I cannot go on with this for all day. I think I've explained enough. It has helped me many times I've bumped into a `docker run` fail, giving me some clues checking if docker keep running or not. Tell what you prefer, I just shared something was useful for me. If it's not for you, it's ok. You can finnish the discussion, I cannot invest more time in this dialogue. I'd like to, but I have no more time for something that won't take us anywhere. Kind regards. – Alejandro Galera Aug 19 '20 at 12:45