部署GitHub Action至AWS ECS时出现npm ERR! command sh -c错误怎么办

1. SIGTERM错误解决办法 #

首先明确：你看到的npm ERR! signal SIGTERM不是npm或代码本身的运行错误，是外部系统向进程发送了终止信号导致进程被强制停止，结合你描述的「前几秒可正常访问API后容器停止的现象，排查方向如下：

• ECS健康检查配置不合理：
  容器启动时ts-node需要编译TS代码，启动耗时较长，若ECS任务定义的健康检查初始延迟时间过短、阈值过严，连续几次健康检查失败后ECS会主动发送SIGTERM终止容器。
  解决：将ECS任务健康检查的初始延迟调整到60s以上，超时时间设为30s，失败阈值放宽到3次，匹配ts-node的启动耗时。
• 任务资源配额不足：
  你的依赖中包含hardhat、ganache这类高资源占用组件，若ECS任务配置的CPU/内存配额低于实际运行需求，系统会主动终止资源超配额的进程。
  解决：将ECS任务的CPU配额调整到1vCPU以上，内存配额调整到2G以上，确认资源是否足够。
• npm作为PID1进程信号转发异常：
  你当前Dockerfile用npm作为入口进程，npm不会正确转发系统信号给子进程（ts-node），收到SIGTERM时会直接终止，连带业务进程退出。
  解决：修改Dockerfile的ENTRYPOINT为直接启动ts-node，避免npm作为中间层：

  # 替换原有ENTRYPOINT
  ENTRYPOINT ["sh", "-c", "NODE_ENV=prod ts-node app.ts"]
  

  同时可以将npm安装命令调整为生产模式，减少冗余依赖：

  RUN npm i --only=production
  

2. npm debug.log找不到的原因 #

日志中提到的debug.log是npm进程被终止瞬间生成在容器内部的临时文件，ECS终止异常容器后，旧容器的所有文件都会被清理，你后续登录的是新启动的容器实例，自然无法找到旧容器内的日志文件。
若需要抓取该日志，可以临时修改启动命令，将npm日志目录挂载到持久化存储（如EFS），或者将npm日志输出重定向到stdout，即可在CloudWatch中查看完整日志内容。

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