如何解决“ OCI运行时创建失败:container_linux.go:349”

时间:2020-06-15 16:58:12

标签: docker flask

我正在码头化Flask应用程序,并且在启动项目时突然出现此错误:

ERROR: for flask  Cannot start service users: OCI runtime create failed: container_linux.go:349: starting container process caused "exec: \"/usr/src/app/entrypoint.sh\": stat /usr/src/app/entrypoint.sh: no such file or directory": unknown

我不确定为什么会抱怨entrypoint.sh不存在,因为它与Dockefile位于同一目录,直到现在我还没有遇到这个问题。

下面是我的Dockerfile:

FROM python:3.8.2-slim

RUN apt-get update && \
    apt-get -y install netcat && \
    apt-get clean

WORKDIR /usr/src/app

COPY ./requirements.txt /usr/src/app/requirements.txt
RUN pip install -r requirements.txt

COPY ./entrypoint.sh /usr/src/app/entrypoint.sh
RUN chmod +x /usr/src/app/entrypoint.sh

COPY . /usr/src/app

CMD ["/usr/src/app/entrypoint.sh"]

任何对此深表赞赏的见识。

1 个答案:

答案 0 :(得分:0)

在几分钟的搜索中没有找到确切的重复项之一,该网站上有很多类似的问题。要对此进行调试:

  1. 可执行文件在容器内部是否存在?有时人们会做错事,例如它们在映像名称之后包含args,这些名称成为docker试图运行的命令。这里不是这种情况。

  2. 如果docker试图运行一个看起来像json字符串的内容,那么CMD / ENTRYPOINT的json语法中通常会出现语法错误。检查缺少的逗号,用单引号代替双引号。这里也不是这种情况。

  3. 通常存在路径问题,命令位于容器内的其他路径中。有时,卷会覆盖该路径上的图像内容。没有运行命令,就不能排除这种情况。

  4. 如果它是容器中存在的shell脚本,请检查该shell脚本的第一行。例如。 #!/bin/bash。在该路径上的该命令必须存在于容器内。如果脚本是在linux主机之外修改的,请确保换行符为linux格式。 Windows换行符将在文件名末尾添加一个额外的字符。这是您最有可能遇到的问题。

  5. 如果命令是容器内存在的二进制文件,则通常是由于缺少链接库引起的。在二进制文件上使用ldd来查看链接的库,并验证容器中是否存在每个文件名。这通常是在针对libc编译的应用程序中看到的,然后在使用musl的Alpine内部运行。解决方法是在Alpine内部编译或静态编译二进制文件。 Shell脚本不太可能出现此问题。

我在FAQ presentation中介绍了这些内容,在演讲者备注中有一些提示。