AKS容器启动失败：升级Ubuntu基础镜像后exec用户进程报无该文件或目录错误

你遇到的standard_init_linux.go:228: exec user process caused: no such file or directory报错，本质是容器启动时执行入口进程找不到对应的文件或者依赖库，90%以上的场景是镜像本身的问题，和AKS集群无关，可按以下步骤排查：

第一步：确认start.sh的换行符格式 #

• 如果你是在Windows环境下编辑的start.sh，默认换行符是CRLF，而Ubuntu 20.04镜像默认仅识别LF换行格式，换行符不匹配会直接触发该报错。
• 排查方法：本地用dos2unix工具转换格式后重新构建镜像测试：dos2unix start.sh

第二步：确认start.sh的shebang行对应解释器存在 #

• 检查start.sh第一行的shebang配置，比如如果写的是#!/bin/bash，需要确认Ubuntu 20.04基础镜像内已经安装了bash：你升级的Ubuntu版本如果是最小化镜像，默认可能只有sh没有bash
• 临时验证方法：把shebang改成#!/bin/sh测试，或者在Dockerfile的RUN阶段新增安装bash的命令：RUN apt update && apt install -y bash

第三步：确认新增工具安装没有覆盖/删除依赖库 #

• 你本次修改新增了1个工具安装，排查该工具的安装过程是否删除了start.sh依赖的系统库，或者修改了系统默认的动态链接器路径
• 验证方法：注释掉新增的工具安装代码，仅保留升级Ubuntu基础镜像的修改，重新构建镜像测试是否正常启动

第四步：本地直接调试镜像排除AKS问题 #

• 本地拉取构建好的镜像直接运行，跳过AKS部署环节：docker run --rm compregistrynp.azurecr.io/agent-se-linux:25319
• 如果本地运行同样报错，即可100%确认是镜像本身问题，和AKS集群无关；如果本地运行正常，再检查AKS节点的容器运行时版本是否和本地测试环境存在差异

临时应急验证方法 #

如果需要快速确认具体报错信息，可以修改Dockerfile的CMD为循环休眠命令，部署后进入容器手动执行start.sh查看具体提示：

# 替换原有CMD行
CMD ["sleep", "3600"]

部署后执行kubectl exec -it <pod名> -n se-agents -- /bin/bash进入容器，手动运行./start.sh查看具体的缺失文件提示。

内容的提问来源于stack exchange，提问作者Nerd in Training