By using AWS re:Post, you agree to the Terms of Use
/ECS Fargate Task Logs Empty When Using a Entrypoint Shell Script/

ECS Fargate Task Logs Empty When Using a Entrypoint Shell Script

0

Scenario:

  • Using ECS Fargate to launch Tasks from a Task Definition ( the container is a Python Django container, running a management command if this matters)
  • Problem: Logs were empty in Cloudwatch for the task run (completely - no data at all, but the log groups and stream were created).
  • When running the container locally, stdout outputted the expected data

After much research and trial and error, I found that using a ENTRYPOINT command with a shell script is the problem. If I were to switch this to run the container with just the raw cli command as the ENTRYPOINT, the logs show in CW as expected. What is the reasoning/problem for this, and is there a different/better way to find out what was going on here besides trial and error?

This Doesn't Work (in docker)

ENTRYPOINT [ "/app/docker-entrypoint.sh" ]
CMD ["run_management_command"]
# docker-entrypoint.sh
# code shortened for a little brevity, may have syntax errors
shift
exec python manage.py "$@"

This Works ( in docker)

CMD ["python", "manage.py", "run_management_command"]

Does the shell script / exec cause the AWS std out logger to become disassociated somehow?

  • In both scenarios, the container runs as expected and does it's job. Just the logging is missing from the docker-entrypoint run

1 Answers
0

I understand that when you are running a shell script as your Entrypoint in the Docker file. When deploying the image in ECS Fargate, you observed that the logs are no longer pushed to cloudwatch. As you might already know, The awslogs log driver simply passes the container logs that are the STDOUT and STDERR I/O streams from Docker to CloudWatch Logs. Now, I understand that you were able to see the logs when running the command directly instead of running as an “exec” in a shell script.

So, since you are running the container on ECS Fargate, you would not be able to access the underlying host where the task is running. Hence, I would suggest that you try launching the same container on EC2 launch type with the same Network configuration as your Fargate tasks. Doing this, once the task gets scheduled on an EC2 worker nodes, you can SSH in to the EC2 worker node and then check if “docker logs <container-name>” shows expected data in the output. Verifying that you are able to run the ECS Task on EC2 container instance would be the next step after verifying that your container runs fine in your local maching. When you run docker logs from within the worker node, you are essentially pulling the STDOUT/STDERR log streams captured from the container. If the docker logs command does not return any output then you can further troubleshoot the issue by trying to exec in to the container to see if the application is running in the container as expected and verify if the application is able to write logs out to the STDOUT.

Considering that we need additional information to be able to completely understand what the issue is, I would suggest that you raise a support ticket with AWS Premium Support to get assistance with this issue.

SUPPORT ENGINEER
answered 23 days ago

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.

Guidelines for Answering Questions