aws/amazon-ecs-cli

ecs-cli logs hangs when there are no task logs

KlotzAndrew opened this issue · 2 comments

ecs-cli logs hangs when there are no task logs

Summary

If a container ran and exited without producing logs, running the command: ecs-cli logs --cluster cluster123 --region us-east-1 --task-id task123 will hang if the container did not produce any logs. Where region, cluster and task-id correspond to the task that ran

Description

  • Which specific command was run? ecs-cli logs
  • Which version of the CLI you are using? ecs-cli version 1.18.0 (3970a6c)
  • Which version of Go are you using? go version go1.14.4 linux/amd64
  • What platform are you using to run ECS CLI commands? Linux

Config files

n/a

Expected Behavior

The command exits successfully printing 0 logs

Observed Behavior

The command hangs

Thanks so much for bringing this up. We welcome external contributions for the ECS CLI these days, so please feel free to cut a PR for this if it's a blocker and I'll be happy to review it!

I am also experiencing a similar hang in one AWS account, but not in others which are pretty much configured the same way and in cases where I know there is task output to be retrieved and the task has finished in the minutes prior

Other subcommands of ecs-cli (such as ps) perform as expected.

I wondered if it was a configuration or permissions issue that causes a problem in the problematic environment, but it isn't obvious to me what that configuration is or how it might be misconfigured in the problematic environment. It is also odd that the behaviour is to hang instead of to error out.

update: another odd detail of our instance of this issue is that when it happens it affects all ecs-logs call on the affected cluster. It also started working again for a few days later for reasons I can't explain and then just as mysteriously stopped working again.

Since our environments are managed with terraform and we have a pretty good handle on when and why are environments are changing. I was prepared to put the first instance of the problem down to an obscure side-effect of a odd configuration sequence which was then corrected when the configuration was re-aligned a day after the problem first occurred. I can't explain why the problem has re-occurred now the configuration has been properly aligned since the problem was first (temporarily) resolved.