Docker報錯:OCI runtime exec failed: exec failed: container_linux.go:380: starting container process的解決方法

詳細信息

[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 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。

到此這篇關於Docker報錯:OCI runtime exec failed: exec failed: container_linux.go:380: starting container process解決的文章就介紹到這瞭,更多相關Docker報錯:OCI runtime exec failed內容請搜索WalkonNet以前的文章或繼續瀏覽下面的相關文章希望大傢以後多多支持WalkonNet!

推薦閱讀: