详细信息

[root@centOS7 ~]# docker exec -it 3cae7605916d /bin/bash


OCI runtime exec failed: exec failed: container_linux.go:380: starting container process caused: exec: “/bin/bash”: stat /bin/bash: no such file or directory: unknown

老规矩：先上答案

把脚本类型 /bin/bash，尝试换为 /bin/sh

试一下，如果你想对两种shell的区别有深入了解，

点击这里

。

注意：

如果你在Dockerfile中引用了自定义脚本，比如：entrypoint:



./entrypoint.sh



，如果没有单独给该脚本通过



chmod +x ./entrypoint.sh



添加执行权限，也可能会报这个错误。

前言

在docker学习中，大部分容器进入的脚本都是/bin/bash，比如tomcat，所以不假思索的认为其他容器进入方式的脚本类型也是/bin/bash，然而这是一个误区。

解析步骤

1.首先，了解一些脚本的类型

[root@centOS7 ~]cat /etc/shells
/bin/sh
/bin/bash
/usr/bin/sh
/usr/bin/bash
/bin/tcsh
/bin/csh
[root@centOS7 ~]# 

本机脚本解释器类型有4种。最常见的是前两种

(usr)


/


bin/sh

和

(usr)


/bin/bash，

还有一些不是很常见的脚本类型：

ash、ksh、csh、zsh

等，不同的shell都有自己的特点以及用途。

2.进入Tomcat容器内部，查Tomcat启动脚本解释器类型

docker exec -it tomcat /bin/bash
ls 
cd bin && ls
cat startup.sh

不难发现，它的启动脚本解释器类型是


/usr/bin/bash

3.进入Nginx容器内部，查Nginx启动脚本解释器类型

exit #退出tomcat容器
docker ps #查看正在运行的容器列表
docker exec -it 3cae7605916d /bin/sh  #进入nginx容器
cd /etc/init.d && ls
cat nginx  #并不是想要/bin/sh结果

发现，首行并不是想要的结果

/bin/bash

，不放弃继续找

find / -name nginx -type f   #仅查找nginx启动文件
find / -name nginx #过滤出目录下所有的nginx

最后的最后，怎么找nginx的启动脚本，

期望能找到首行的解释器是


/bin/sh

，但是事与愿违，不是乱码就是/sbin/openrc-run。

总结

经过各种求教，得到的答案，nginx:alpine精简版，在做镜像的时候，只装了sh，没有装bash，所以用不了bash。shell类型有很多种，但是sh类型的shell是最基础的，所以大部分镜像都支持。这就不难理解为什么docker exec -it  可以使用 /bin/sh进入镜像内部了。

docker exec使用小技巧：后面的/bin/或者/usr/bin/可以省略掉，直接写sh 或者 bash。