0

I'm dockerizing Flask app and when bringing up the project I get this error all the sudden:

ERROR: for flask  Cannot start service users: OCI runtime create failed: container_linux.go:349: starting container process caused "exec: \"/usr/src/app/entrypoint.sh\": stat /usr/src/app/entrypoint.sh: no such file or directory": unknown

I'm not sure as to why is it complaining about entrypoint.sh not existing because it's in the same directory as the Dockefile and up until now I wasn't encountering this issue.

below is my Dockerfile:

FROM python:3.8.2-slim

RUN apt-get update && \
    apt-get -y install netcat && \
    apt-get clean

WORKDIR /usr/src/app

COPY ./requirements.txt /usr/src/app/requirements.txt
RUN pip install -r requirements.txt

COPY ./entrypoint.sh /usr/src/app/entrypoint.sh
RUN chmod +x /usr/src/app/entrypoint.sh

COPY . /usr/src/app

CMD ["/usr/src/app/entrypoint.sh"]

Any insight into this much appreciated.

road_runner
  • 459
  • 1
  • 5
  • 15

1 Answers1

0

Didn't find one of the exact duplicates in a couple minutes of searching, there are quite a few similar questions on the site. To debug this:

  1. Does the executable exist, inside the container? Sometimes people run the wrong thing, e.g. they include args after the image name that become the command docker is trying to run. That's not the case here.

  2. If docker is trying to run what looks like a json string, then there is often a syntax error in the json syntax of the CMD/ENTRYPOINT. Check for missing commas, single quotes instead of double quotes. This also isn't the case here.

  3. Often there are path issues, commands are in a different path inside the container. Sometimes a volume overwrites the image contents at that path. Without your run command, this can't be ruled out.

  4. If it's a shell script that exists inside the container, check the first line of that shell script. E.g. #!/bin/bash. That command, at that path, must exist inside the container. If the script was modified outside of a linux host, make sure the linefeeds are in the linux format. Windows linefeeds will result in an extra character at the end of the filename. This is the most likely issue for you.

  5. If the command is a binary that exists inside the container, then it's often caused by a missing linked library. Use ldd on the binary to see the linked libraries and verify each filename exists inside the container. This is often seen with apps compiled against libc and then run inside of Alpine which uses musl. The fix is to compile inside of Alpine, or statically compile the binary. This is unlikely your issue with a shell script.

I cover these in a FAQ presentation which has some hints in the speaker notes.

BMitch
  • 231,797
  • 42
  • 475
  • 450
  • And now I just found two similar answers from myself: https://stackoverflow.com/a/55182591/596285 and https://stackoverflow.com/a/51770158/596285 – BMitch Jun 15 '20 at 17:48
  • Thank you for all the useful info. I noticed that I'm getting this error only when running / building the container on AWS cluster. Locally it's running fine but there's something happening on AWS that throws this error. Normally I'd SSH into the container and run diagnostics but the container won't even launch so I won't get any more insight what's happening in the container. – road_runner Jun 17 '20 at 07:53