runc · Docker
報錯原文
standard_init_linux.go: exec user process caused: no such file or directory
這是什麼意思
容器要執行它的入口點，核心回答「no such file」——陷阱在於那個檔案明明就在那裡。指令碼的行尾是 CRLF，於是第一行被讀成 #!/bin/sh\r，核心便去找一個名字真的叫 sh\r 的解譯器；在 Windows 上複製、或者開著 git 的 autocrlf，正是這個結果。dos2unix entrypoint.sh 能轉換那一個檔案（沒有它就用 sed -i 's/\r$//' entrypoint.sh），而在 .gitattributes 裡寫一行 *.sh text eol=lf 能防止它再來。在 #! 裡寫了映像中並不存在的解譯器——比如 alpine 映像裡的 bash——也會給出同樣的字。
怎麼修
dos2unix entrypoint.sh- 來自
- runc
- Docker
- 12
docker 的錯誤要先歸到某一層才讀得懂——用戶端連不上守護行程、映像檔倉庫拒絕你、建置過程中某條 RUN 失敗、容器一起來就死掉，是四種不同的問題——而在建置和執行這兩層，那行字本身並不是原因：原因在裡面那條命令留下的輸出裡，各層修復的代價也不一樣。
怎麼讀報錯
- 從第一行往下讀。越往下越是工具內部的事，起因通常寫在最上面。
- 有檔名和行號就從那裡查——不是堆疊最上面那一格，而是最上面那條提到你自己寫的檔案的行。
- 把報錯原文照樣去搜，但先去掉你自己的路徑和變數名，正是那些讓搜尋比對不上。
- 同一種情況在不同版本裡措辭不同。結果不對頭，就把版本號一起加進查詢。
- 貼上修法之前，先確認它會丟掉什麼。這裡面有些是不能收回的。
常見問題
Q. “standard_init_linux.go: exec user process caused: no such file or directory” 是什麼意思？
容器要執行它的入口點，核心回答「no such file」——陷阱在於那個檔案明明就在那裡。指令碼的行尾是 CRLF，於是第一行被讀成 #!/bin/sh\r，核心便去找一個名字真的叫 sh\r 的解譯器；在 Windows 上複製、或者開著 git 的 autocrlf，正是這個結果。dos2unix entrypoint.sh 能轉換那一個檔案（沒有它就用 sed -i 's/\r$//' entrypoint.sh），而在 .gitattributes 裡寫一行 *.sh text eol=lf 能防止它再來。在 #! 裡寫了映像中並不存在的解譯器——比如 alpine 映像裡的 bash——也會給出同樣的字。
Q. 怎麼修？
dos2unix entrypoint.sh —— 執行前先看上面的說明，確認這條命令會丟掉什麼。
Q. 這是哪個工具報的？
runc。它屬於Docker，報錯原文有 10 個詞。