Azure Ubuntu虚拟机RunCommand执行异常终止问题排查

核心现象复盘 #

• 通过ARM/Bicep部署的RunCommand脚本，执行到Docker镜像拉取步骤后突然终止，waagent日志显示exit status=-1及Timeout:signal: killed，但模板中已配置5分钟（300秒）超时
• 当镜像已存在时，脚本可快速完成并成功启动容器
• 此前执行包含sudo gluster volume create的RunCommand时，也出现过类似无预警终止的情况，且已确保单VM上RunCommand串行执行

排查步骤 #

1. 验证超时配置的实际生效情况 #

• 检查ARM/Bicep模板中RunCommand的timeoutInSeconds参数是否明确设置为300，避免嵌套部署或默认值覆盖导致超时被设为更短时间
• 登录VM查看waagent本地配置：打开/etc/waagent.conf，确认RunCommandExecutionTimeout的值是否与模板配置一致，部分场景下本地配置优先级高于模板
• 手动在VM上执行完整脚本，记录首次拉取镜像的实际耗时，若接近或超过5分钟，日志中的“Timeout”提示可能准确，只是脚本实际执行时间超出配置值

2. 排查系统资源限制导致的进程被杀死 #

• 检查系统OOM（内存不足）日志：查看/var/log/syslog或执行dmesg | grep "killed process"，确认是否有因内存不足被系统杀死的进程记录
• 查看waagent服务日志：执行journalctl -u waagent.service，排查是否有资源不足导致进程终止的相关提示
• 测试磁盘IO影响：若VM使用Standard HDD，临时更换为SSD磁盘重新执行脚本，验证是否因磁盘IO性能不足导致脚本进程被系统终止

3. 检查RunCommand的执行环境与权限 #

• 导出执行环境变量：在脚本开头添加env > /tmp/runcommand_env.log，对比手动执行脚本时的环境变量（如Docker的PATH），排查环境变量缺失问题
• 记录权限上下文：在脚本关键步骤前添加whoami >> /tmp/runcommand_debug.log和groups >> /tmp/runcommand_debug.log，确认执行用户的权限组是否符合命令要求（比如gluster命令需要的组权限）

4. 细化脚本执行日志定位终止点 #

• 在脚本每个关键步骤后添加详细日志：

  echo "ACR登录完成: $(date)" >> /tmp/runcommand_debug.log
  echo "镜像拉取完成: $(date)" >> /tmp/runcommand_debug.log
  echo "旧容器清理开始: $(date)" >> /tmp/runcommand_debug.log
  

  通过日志确认脚本具体在哪个步骤后被终止
• 拆分脚本为多个独立RunCommand：将登录ACR、拉取镜像、启动容器拆分为单独的RunCommand步骤，排查是否是某个特定步骤触发的终止逻辑

5. 升级waagent版本修复兼容性问题 #

• 检查当前waagent版本：执行waagent --version
• 升级到最新稳定版本：

  sudo apt update && sudo apt install --only-upgrade walinuxagent
  

• 重启waagent服务：sudo systemctl restart waagent.service，重新测试RunCommand

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