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 mcr.microsoft.com/dotnet/aspnet:6.0.
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 docker_entrypoint.sh file and added the long command inside of it. Then called it from entrypoint:
#!/bin/sh
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/docker_entrypoint.sh"]
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/sh
(#!/bin/bash would work too)
That gave me this error in docker run:
exec /app/docker_entrypoint.sh: exec format error
Adding the declaration fixed the problem.
Then I got the second issue (again in docker run):
exec /app/docker_entrypoint.sh: 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 docker_entrypoint.sh. 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/docker_entrypoint.sh": permission denied: unknown
The fix was simple, to give execute permissions to the script, in Dockerfile:
RUN chmod +x /app/docker_entrypoint.sh
An update that would be simple can sometimes be a confused endeavour, specially when mixing Windows and Linux 🙂