Dockerfile Entrypoint with multiple params using a shell script

Dockerfile Entrypoint with multiple params using a shell script


2 min read

I'm working with a .NET 6 microservice to which I needed to integrate a new profiler tool, for a proof of concept requested by the QA team.

The app has a Dockerfile and runs in a Linux container from base image

At the end of the Dockerfile I had this typical entrypoint:

ENTRYPOINT ["dotnet", "Myapp.dll"]

In order to integrate the profiler, I needed to start my application in a different way, with a longer command, like this:

dotnet /tmp/sl-dotnet-agent/SL.DotNet.dll testListener --buildSessionIdFile /tmp/sl-dotnet-agent/buildSessionId.txt --target dotnet --workingDir /app --targetArgs "Myapp.dll"

The solution I found convenient was to create a shell script, and reference the shell script in entrypoint. So I created a file and added the long command inside of it. Then called it from entrypoint:

echo Will start the app with the profiler
dotnet /tmp/sl-dotnet-agent/SL.DotNet.dll testListener --buildSessionIdFile /tmp/sl-dotnet-agent/buildSessionId.txt --target dotnet --workingDir /app --targetArgs "Myapp.dll"
ENTRYPOINT ["/app/"]

This was supposed to be a straightforward update, but I got a few issues.

To start with, the first time I created the shell script, I forgot to include the shell script declaration (shebang or a "bang" line) at the top:


(#!/bin/bash would work too)

That gave me this error in docker run:

exec /app/ exec format error

Adding the declaration fixed the problem.

Then I got the second issue (again in docker run):

exec /app/ no such file or directory

I was certain the file existed in that path... So, why?

I'm developing in Windows (not because I want to, but that's for another topic). The line endings in Windows (CR + LF) are different from Linux (LF). It turns out that I wrote my shell script with Windows line endings, and that triggered the no such file or directory error. Weird, no? ๐Ÿค”

I fixed it by using Notepad++. It has this nice line ending conversion feature in Edit => EOL Conversion.

The last issue I got had to do with permissions to execute the shell script I noticed the problem in AKS, when Kubernetes was trying to start the container. The error message from kubectl get events was:

Error: failed to create containerd task: failed to create shim: OCI runtime create failed: container_linux.go:380: starting container process caused: exec: "/app/": permission denied: unknown

The fix was simple, to give execute permissions to the script, in Dockerfile:

RUN chmod +x /app/

An update that would be simple can sometimes be a confused endeavour, specially when mixing Windows and Linux ๐Ÿ™‚