ECS任务一接收请求即崩溃，退出码129且无可用日志

问题详情 #

向ECS Fargate任务发起请求时，任务立即崩溃，任务详情显示“任务中的必要容器已退出”，退出码为129，且无任何日志输出。本地运行服务完全正常，ELB也未发现健康问题。

相关截图 #

任务定义 #

{
  "family": "<family>",
  "requiresCompatibilities": ["FARGATE"],
  "executionRoleArn": "<role>",
  "networkMode": "awsvpc",
  "runtimePlatform": {
    "operatingSystemFamily": "LINUX",
    "cpuArchitecture": "ARM64"
  },
  "cpu": "1024",
  "memory": "2GB",
  "containerDefinitions": [
    {
      "name": "<name>",
      "image": "<image>",
      "portMappings": [
        {
          "protocol": "tcp",
          "appProtocol": "http",
          "containerPort": 80
        }
      ],
      "cpu": 1024,
      "memory": 2048,
      "essential": true,
      "logConfiguration": {
        "logDriver": "awslogs",
        "options": {
          "awslogs-group": "ecs-prod",
          "awslogs-region": "ap-northeast-2",
          "awslogs-stream-prefix": "prod"
        }
      }
    }
  ]
}

ECS服务配置 #

{
  "cluster": "<name>",
  "serviceName": "prod-service",
  "taskDefinition": "<def name>",
  "loadBalancers": [
    {
      "targetGroupArn": "<arn>",
      "containerName": "<container name>",
      "containerPort": 80
    }
  ],
  "launchType": "FARGATE",
  "schedulingStrategy": "REPLICA",
  "deploymentController": {
    "type": "CODE_DEPLOY"
  },
  "platformVersion": "LATEST",
  "networkConfiguration": {
    "awsvpcConfiguration": {
      "assignPublicIp": "ENABLED",
      "securityGroups": ["sg"],
      "subnets": ["s1", "s2", "s3"]
    }
  },
  "desiredCount": 1
}

排查建议 #

1. 明确退出码129的触发原因 #

退出码129对应SIGHUP信号，即容器进程收到挂起信号后退出，常见场景：

• 容器主进程不是PID 1，无法正确处理系统信号
• 负载均衡请求/健康检查触发了进程异常信号逻辑
• 容器资源限制间接引发信号终止（但129更偏向信号直接触发）

2. 优先解决无日志问题 #

• 检查ECS执行角色权限：确保角色拥有logs:CreateLogStream、logs:PutLogEvents权限，否则日志无法写入CloudWatch
• 临时修改任务定义，添加命令强制输出启动日志，示例：

  "containerDefinitions": [
    {
      ...
      "command": ["/bin/sh", "-c", "your-start-command && tail -f /dev/null"]
    }
  ]
  

• 查看ECS任务详情页的完整Stopped Reason信息（截图可能未展示全部内容）

3. 修复容器PID 1问题 #

多数应用镜像的主进程并非PID 1，导致无法正确接收系统信号，可通过两种方式解决：

• 修改Dockerfile，用exec命令启动应用，确保它成为PID 1：

  ENTRYPOINT ["exec", "your-app-command"]
  

• 在任务定义的command字段中用exec包裹启动命令

4. 验证负载均衡与容器的交互逻辑 #

• 核对目标组健康检查路径：确认和本地运行时的健康检查路径一致，路径错误可能触发应用异常
• 临时关闭负载均衡健康检查，手动向容器公网IP发起请求，排查是负载均衡触发还是所有请求都会导致崩溃
• 检查安全组规则：确认容器所在安全组允许来自负载均衡的流量，同时容器内应用确实在80端口监听

5. 确认架构兼容性 #

任务定义指定了ARM64架构，需验证镜像适配性：

• 本地x86机器开启Docker ARM模拟后可能运行正常，但Fargate ARM64环境下存在兼容性问题
• 重新构建镜像时指定--platform linux/arm64，或用docker inspect <image>查看镜像的Architecture字段确认架构

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