EC2实例用户数据脚本未完成运行 手动执行可正常启动Puma服务

• 伪终端（PTY）缺失
  你的启动脚本大概率使用了带-t参数的docker run/docker-compose run命令，该参数要求分配伪终端才能正常运行。用户数据由cloud-init在非交互式无终端的系统后台执行，不提供PTY，导致容器创建完成后直接退出，Puma进程无法持续运行。而SSH登录场景下默认分配伪终端，命令可以正常执行。
  从日志差异也可佐证：用户数据执行时仅输出到容器创建完成就终止，没有后续Puma启动日志，符合无PTY时容器提前退出的特征。
• 工作目录不匹配
  SSH执行命令前你已经切换到了应用根目录，而用户数据脚本执行时默认工作目录是/root，如果脚本中没有显式执行cd /path/to/your/app切换到应用目录，相对路径引用的docker-compose.yml、.env配置文件、挂载目录都会找不到，导致服务启动失败。
• 环境变量缺失
  你在AMI中为ec2-user配置的环境变量（存放在~/.bashrc、~/.profile、/etc/profile.d/下的自定义脚本）默认不会加载到cloud-init的root执行环境中。如果你的服务启动依赖这类变量（比如Docker镜像地址、Rails密钥等未在Docker配置中硬编码的参数），就会导致启动流程中断。你可以观察到两类执行日志的差异：用户数据执行时变量缺失提示没有WARNING前缀，也印证了两个执行环境的Rails运行配置不一致。
• 依赖服务未就绪
  用户数据执行时机在实例启动流程中较早，可能出现Docker服务还未完全初始化完成就执行了启动脚本的情况，导致容器创建异常但没有报错输出。SSH登录时实例已经完成所有系统服务初始化，所以执行正常。

• 调整Docker启动命令，去掉-t参数，或者添加-d参数让容器后台运行，避免依赖伪终端
• 用户数据脚本开头先显式切换到应用根目录，例如cd /home/ec2-user/your-app-directory
• 所有启动需要的环境变量在用户数据脚本中显式export，或者写入/etc/environment全局生效
• 执行启动脚本前添加等待Docker就绪的逻辑，例如：

until systemctl is-active --quiet docker; do
  sleep 1
done

内容的提问来源于stack exchange，提问作者Chris G.