DigitalOcean App部署Docker化Python应用启动start.sh报exec format error

需要明确的是，这个报错和你尝试调整的start.sh执行权限无关——权限不足的场景下，系统会直接返回permission denied提示，能触发exec format error的场景只有两类：

报错的核心触发原因 #

• 运行架构不匹配：如果你本地构建镜像的环境是ARM架构（比如苹果M系列芯片的开发设备），但DigitalOcean的容器运行时为x86_64架构，跨指令集运行的镜像会在加载进程时触发格式校验失败，直接抛出这个错误。
• 脚本格式与结构不合法：你当前的start.sh存在两个硬伤：一是没有声明脚本解释器的shebang头，二是如果脚本是在Windows环境下编辑保存的，会携带CRLF换行符，Linux内核无法识别这类文件的可执行格式，即使提前加了执行权限也无法正常加载。

具体修复操作 #

1. 简化启动链路，消除脚本带来的报错 #

• 调整start.sh的合法格式，补充shebang头，确保文件保存时使用Linux兼容的LF换行格式：

  #!/bin/bash
  gunicorn -b :5000 --access-logfile - --error-logfile - pixelshop:app
  

• 更推荐的做法是去掉shell脚本中转环节，直接在Dockerfile中以JSON格式定义ENTRYPOINT启动Gunicorn，从根源上规避脚本格式、权限带来的不确定问题。将原本的ENTRYPOINT ./start.sh替换为：

  ENTRYPOINT ["gunicorn", "-b", ":5000", "--access-logfile", "-", "--error-logfile", "-", "pixelshop:app"]
  

  这种写法会直接将Gunicorn作为容器主进程启动，不会额外衍生无意义的shell中转进程，也能保证容器正常接收终止信号，实现优雅退出。

2. 解决架构不匹配问题 #

• 放弃使用python:latest这类浮动标签的基础镜像，这类标签会随官方推送自动更新架构版本，很容易出现和目标平台不兼容的问题。将Dockerfile的第一行调整为固定指定amd64平台的稳定Python版本：

  FROM --platform=linux/amd64 python:3.11-slim
  

  用slim版本替代latest不仅能避免架构漂移的问题，还能大幅缩小镜像体积，加快部署启动速度。
• 保留你原本的依赖安装逻辑即可，可将多个独立的RUN指令合并以减少镜像层数，比如把apt更新、系统依赖安装的步骤合并为单条指令，避免构建缓存导致的包缺失问题。

3. 常见的认知误区 #

你之前反复调整start.sh执行权限的操作完全没有针对性：文件格式校验、架构校验的流程要早于权限校验环节，如果是前两类问题，流程根本走不到权限检查的步骤，所以无论怎么调整chmod的参数，报错都不会消失。

内容的提问来源于stack exchange，提问作者Udendu Abasili