standard_init_linux.go:211：exec 用户进程导致“没有这样的文件或目录”？

Posted 2023-02-21

【中文标题】standard_init_linux.go:211：exec 用户进程导致“没有这样的文件或目录”？

【英文标题】：standard_init_linux.go:211: exec user process caused "no such file or directory"?

【发布时间】：2020-08-03 07:35:20

【问题描述】：

Dockerfile

FROM python:3.7.4-alpine

ENV PYTHONUNBUFFERED 1
ENV PYTHONDONTWRITEBYTECODE 1
ENV LANG C.UTF-8
MAINTAINER "[e-mail]"


RUN apk update && apk add postgresql-dev gcc musl-dev
RUN apk --update add build-base jpeg-dev zlib-dev
RUN pip install --upgrade setuptools pip

RUN mkdir /code
WORKDIR /code

COPY requirements.txt /code/
RUN pip install -r requirements.txt
COPY . /code/

#CMD ["gunicorn", "--log-level=DEBUG", "--timeout 90", "--bind", "0.0.0.0:8000", "express_proj.wsgi:application"]
ENTRYPOINT ["./docker-entrypoint.sh"]

docker-entrypoint.sh

#!/bin/bash

# Prepare log files and start outputting logs to stdout
touch /code/gunicorn.log
touch /code/access.log
tail -n 0 -f /code/*.log &

# Start Gunicorn processes
echo Starting Gunicorn.
exec gunicorn express_proj.wsgi:application \
    --name express \
    --bind 0.0.0.0:8000 \
    --log-level=info \
    --log-file=/code/gunicorn.log \
    --access-logfile=/code/access.log \
    --workers 2 \
    --timeout 90 \
    "$@"

出现错误 standard_init_linux.go:211: exec 用户进程导致“没有这样的文件或目录” 需要帮忙。 有人说要用dos2unix（我不知道怎么用。）

【问题讨论】：

您的图像是否真的包含 GNU bash？ （Alpine 图像通常不会。）我认为您的脚本没有使用任何特定于 bash 的功能，因此 Alpine 中的 POSIX shell 应该可以正常工作；将 shebang 行更改为 #!/bin/sh 有效吗？

坦克斯。它正在工作。

【参考方案1】：

脚本开头的“shebang”行说明了使用什么解释器来运行它。在您的情况下，您的脚本已指定 #!/bin/bash，但基于 Alpine 的 Docker 映像通常不包含 GNU bash；相反，他们有一个更小的/bin/sh，其中仅包含 POSIX shell 规范中的功能。

您的脚本未使用任何非标准 bash 扩展，因此您只需将脚本的开头更改为

#!/bin/sh

【讨论】：

更改后，我得到 [2020-04-21 06:18:28 +0000] [10] [INFO] Booting worker with pid: 10。这是什么意思？我无法在任何地方解决它。

这似乎是来自gunicorn 的正常输出，我认为您不需要对此做任何事情。开始提出请求吧。

【参考方案2】：

如果脚本的行尾错误也可能发生这种情况，即\r\n 而不是\r

这可以使用file path/to/script.sh 命令检查，该命令告诉脚本是否有CR-LF 行结尾

如果它是一次性脚本，可以使用 dos2unix 将其更改为 \r\n 到 \n

如果它是一个 git 存储库，将 autocrlf 选项设置为 input 将起作用

How to change line-ending settings

【讨论】：

谢谢！为我节省了几天毫无头绪的研究！！ – 这是一个非常罕见的解决方案，但这是我难以诊断的问题。我的项目在 Linux 和 MacOS 上运行，但在 Windows (WSL) 上克隆和重建时无法运行 shel 脚本。将*.sh eol=lf 和*.bat eol=crlf 添加到新创建的.gitattributes（提交到存储库）中，解决了git pull --rebase 获取属性规则后Windows 机器上的问题（因此在处理@ 时修复了行尾987654334@ 的 shell 脚本）。