"exec format error" for ENTRYPOINT pointing to shell script lacking shebang line

[anentropic]

I'm posting this here because error message is raised by a file in this project:

standard_init_linux.go:195: exec user process caused "exec format error"

As an end user I'd like it if somehow it was possible to give a more informative error.

However I have identified what I was doing wrong to cause the error so feel free to close this issue, I mainly wanted it saved somewhere so anyone else having same problem could find the solution in google.

$ docker version
Client:
 Version:      17.04.0-ce
 API version:  1.28
 Go version:   go1.7.5
 Git commit:   4845c56
 Built:        Wed Apr  5 23:33:17 2017
 OS/Arch:      darwin/amd64

Server:
 Version:      17.12.1-ce
 API version:  1.35 (minimum version 1.12)
 Go version:   go1.9.4
 Git commit:   7390fc6
 Built:        Tue Feb 27 22:20:43 2018
 OS/Arch:      linux/amd64
 Experimental: false

What happened is I had a Dockerfile like:

FROM python:3.6-slim

...

ENTRYPOINT ["pipenv", "run", "celery", "worker"]

Then I wanted to add a "--loglevel=$LOGLEVEL" segment to the entrypoint, but env vars are not interpolated there. So I found the advice to move my startup commands into a shell script and use that as my ENTRYPOINT instead.

I created an entrypoint.sh containing:

pipenv run celery worker --loglevel=$LOGLEVEL $@

and set file permission to executable.

But then when I docker run I get

standard_init_linux.go:195: exec user process caused "exec format error"

This is puzzling because if I manually run ./entrypoint.sh from the command line it works

By trial end error I found that adding the shebang, i.e.

#!/bin/bash
pipenv run celery worker --loglevel=$LOGLEVEL $@

fixed the problem.

I guess this is something to do with how the exec process works vs running in a terminal shell session.

Googling for this error message turned up some quite disparate causes, eg

• several issues in moby project like standard_init_linux.go:195: exec user process caused "exec format error" moby/moby#35447 caused by mismatch in architecture of binaries vs docker host
• this blog post https://blog.hompus.nl/2018/01/24/docker-run-throws-exec-user-process-errors/ where seemed like changing encoding of file away from utf8 fixed problem

I wonder if the error message can be more informative or specific to separate problems.

[cyphar]

The -ENOEXEC error comes from the kernel, so it's not really trivial to figure out why such an error happened. While you could argue that checking whether a file has a shebang line isn't that hard, the problem is that the context in which exec is called is the last possible point in the execution of runc before we start executing user code -- so having these sorts of helpers would be pretty hard.

Not to mention they would probably cause more problems than they solve -- how do we know that a missing shebang line was the cause of the problem -- it could also have been an architecture issue as well (architecture issues have the same error because the kernel provides the same error).

[ibnesayeed]

Not to mention they would probably cause more problems than they solve -- how do we know that a missing shebang line was the cause of the problem -- it could also have been an architecture issue as well (architecture issues have the same error because the kernel provides the same error).

If pin-pointing a specific reason is difficult, but possible reasons are finite, an error message can perhaps list them all to allow the user to figure out which of the listed reasons can potentially be causing the failure. That will still be an improvement over the current state of users having no clue what the exception really means.