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 个词。