For the last couple of hours I have been trying to start my startup.sh script on docker container start, but for some reason it doesn't work.
My Dockerfile to create the image:
FROM armv7/armhf-ubuntu:latest
MAINTAINER Mohammed Noureldin <m.n.e#hotmail.com>
RUN apt update && apt upgrade -y && apt install -y mumble-server
ADD scripts/startup.sh /startup.sh
My startup script:
#!/bin/bash
/etc/init.d/mumble-server start
Nothing happens here, though I tried to create a file inside the script but also nothing happened!
I tried to execute the script directly from command line, but it doesn't work I don't know why:
docker run command:
docker run --name murmur -itd --restart always --network bridge -p 64738:64738 -v /var/lib/mumble-server/ -v /etc/ mnoureldin/murmur:latest /bin/bash -c "bash /startup.sh;/bin/bash"
And here what I get when trying to execute the script manually:
43b9d8dd4116bc605537c7af35ab186ca165ea6e957fab5908d39b2f085edf41
mohammed#server01:~/Dockerfiles/Mumble $ docker attach murmur
root#43b9d8dd4116:/# bash
.dockerenv boot/ etc/ lib/ mnt/ proc/ run/ srv/ sys/ usr/
bin/ dev/ home/ media/ opt/ root/ sbin/ startup.sh tmp/ var/
root#43b9d8dd4116:/# bash startup.sh
Usage: /etc/init.d/mumble-server {start|stop|restart|force-reload}
Or when I have an empty line between the two lines of the script I get this error:
root#830193e67fd7:/# bash startup.sh
startup.sh: line 2: $'\r': command not found
Usage: /etc/init.d/mumble-server {start|stop|restart|force-reload}
Could some one explain what is heppening and why it doesn't work?
The error is caused by the line endings in your shell script. It looks like you're using Windows line endings (CRLF, or \r\n), where the unexpected r is confusing Bash. Bash only expects LF or \n, hence the error message.
Most programmer text editors have some kind of support for making these changes. Notepad++ has "Edit > EOL Conversion > Unix/OSX Format". Please see EOL conversion in notepad ++ for more info.
Related
Following the instructions as outlined to deploy Duo CloudMapper to AWS environment and getting an error
Docker File
FROM python:3.7-slim as cloudmapper
LABEL maintainer="https://github.com/0xdabbad00/"
LABEL Project="https://github.com/duo-labs/cloudmapper"
WORKDIR /opt/cloudmapper
ENV AWS_DEFAULT_REGION=us-east-1
RUN apt-get update -y
RUN apt-get install -y build-essential autoconf automake libtool python3.7-dev python3-tk jq awscli
COPY cloudmapper/. /opt/cloudmapper
COPY entrypoint.sh /opt/cloudmapper/entrypoint.sh
# Remove the demo data
RUN rm -rf /opt/cloudmapper/account-data/demo
# Install the python libraries needed for CloudMapper
RUN cd /opt/cloudmapper && pip install -r requirements.txt
ENTRYPOINT /opt/cloudmapper/entrypoint.sh
Now building the docker image
C:\> docker build -t cloudmapper .
When I run the docker using the below command I get an error
C:/> docker run -t cloudmapper
Error
/bin/sh: 1: /opt/cloudmapper/entrypoint.sh: not found
Verified that the file exists in the appropriate location
Using Docker on Windows 10
Image in the dockerfile is python:3.7-slim
Assuming the images are removed and replaced with text and the question doesn't get closed.
bash can return "file not found" when
the entrypoint shell script is not marked executable for the current user
the hash bang in the entrypoint shell script points to a binary that does not exist
the shell script actually does not exist.
You can fix the first problem by ensuring you use the new --chmod flag to ensure the executable bit is set. Even if the user is root it is necessary that there is at least 1 executable bit set.
COPY --chmod=0755 *.sh /opt/cloudmapper/
ENTRYPOINT ["/opt/cloudmapper/entrypoint.sh"]
ps. This integrated COPY --chmod only works with buildkit enabled builds, so you might need to force buildkit, or split the chmod into a separate explicit RUN step.
The 2nd issue can be dealt with by ensuring the first line of entrypoint.sh uses sh rather than bash if you are using a lightweight base image like alpine:
#!/bin/sh
set -e
# etc
Also, if on Windows especially, ensure ALL files, especially the entrypoint .sh file, are set to utf-8 encoding with lf style line endings. As linux doesn't understand the cr, it will try to execute /bin/sh<cr> as the shell which clearly doesn't exist.
In terms of the file not existing, verify the entrypoint.sh is being copied into a location that is referenced by env.PATH, or that the entry point directive uses a fully qualified path.
--
edited to add cr-lf revelation.
everyone!
I'm using a Docker on Windows and I have a Docker file to provide a "varnish" installation and use, but when I run the docker compose I get an error on Varnish container and I don't know what I need do to fix that - the Varnish container is in restarting loop. This is the docker file of Varnish:
FROM 1and1internet/ubuntu-16
RUN apt-get update -y && apt-get install varnish -y
RUN apt-get install nano -y
COPY default.vcl /etc/varnish/default.vcl
ENV VARNISH_START /usr/sbin/varnishd -j unix,user=varnish -F -f /etc/varnish/default.vcl -a 0.0.0.0:6081 -s malloc,1g
EXPOSE 6081
ADD start.sh /start.sh
RUN chmod +x /start.sh
CMD ["/start.sh"]
and the error is (I get this on Docker container logs):
/init/entrypoint: /start.sh: /bin/bash^M: bad interpreter: No such file or directory
In start.sh I have this code:
#!/bin/bash
${VARNISH_START}
Someone can say me what I need do to fix that and run the Varnish container?
^M is the Carriage-Return character. You can see that the error is that it can't find /bin/bash^M
It looks like you've edited the start.sh with a tool like "Notepad" which has given it windows-style CRLF line endings (particularly to the shebang), rather than the linux-style LF which the container is expecting.
Using a 'proper' programming editor, such as Notepad++ or VSCode, you can change the line-endings to LF only. dos2unix on a linux system will also do this.
If you are using GIT for Windows, there's a chance that this is the culprit, as it messes with line-endings unless you tell it not to.
(You get to recognise ^M when you've been bitten by this yourself a few times!)
I have a super dumb script
$ cat script.sh
cat <<EOT > entrypoint.sh
#!/bin/bash
echo "$#"
EOT
docker run -it --rm -v $(pwd)/entrypoint.sh:/root/entrypoint.sh --entrypoint /root/entrypoint.sh bash:4 Hello World
But when I run script I got strange error:
$ sh script.sh
standard_init_linux.go:207: exec user process caused "no such file or directory"
Why script does not print Hello world ?
standard_init_linux.go:207: exec user process caused "no such file or directory"
The above error means one of:
Your script actually doesn't exist. This isn't likely with your volume mount but it doesn't hurt to run the container without the entrypoint, just open a shell with the same volume mount and list the file to be sure it's there. It's possible for the volume mount to fail on desktop versions of docker where the directory isn't shared to the docker VM and you end up with empty folders being created inside the container instead of mounting your file. When checking from inside of another container, also make sure you have execute permissions on the script.
If it's a script, the first line pointing to the interpreter is invalid. Make sure that command exists inside the container. E.g. alpine containers typically do not ship with bash and you need to use /bin/sh instead. This is the most common issue that I see.
If it's a script, similar to above, make sure your first line has linux linefeeds. A windows linefeed adds and extra \r to the name of the command trying to be run, which won't be found on the linux side.
If the command is a binary, it can refer to a missing library. I often see this with "statically" compiled go binaries that didn't have CGO disabled and have links to libc appear when importing networking libraries.
If you use json formatting to run your command, I often see this error with invalid json syntax. This doesn't apply to your use case, but may be helpful to others googling this issue.
This list is pulled from a talk I gave at last year's DockerCon: https://sudo-bmitch.github.io/presentations/dc2018/faq-stackoverflow.html#59
First of all:
Request
docker run -it --rm bash:4 which bash
Output
/usr/local/bin/bash
So
#!/bin/bash
Should be changed to
#!/usr/local/bin/bash
And
docker run -it --rm -v $(pwd)/entrypoint.sh:/root/entrypoint.sh --entrypoint /root/entrypoint.sh bash:4 Hello World
Gives you
Hello World
Update
Code
cat <<EOT > entrypoint.sh
#!/bin/bash
echo "$#"
EOT
Should be fixed as
#!/usr/bin/env bash
cat <<EOT > entrypoint.sh
#!/usr/bin/env bash
echo "\$#"
EOT
Running Docker Toolbox on Windows 10 host.
There is a Dockerfile:
FROM 16.04
...
RUN if [ some_condition ]; then ./foo.sh; fi
...
There is a foo.sh:
#!/bin/bash
...
echo 'Me working'
Now when trying to build the Docker image:
docker build -t name_of_the_image .
Getting error:
Step 7/12 : RUN ./foo.sh
---> Running in e7e0703d3f8f
/bin/sh: 1: ./foo.sh: not found
The command '/bin/sh -c ./foo.sh' returned a non-zero code: 127
I would assume error 127 would be the Docker doesn't see the bash. Any suggestion how to fix this?
Edit: already copying all files into the Docker, Dockerfile:
FROM ubuntu:16.04
MAINTAINER Mr Anderson "mr#anderson.com"
# set workdir
COPY . /app
WORKDIR /app
# Run scripts
RUN ./foo.sh
You'll need to copy/COPY the file into the container before you can execute/RUN the script.
Also since you're using a relative path when you call the script be sure to set a WORKDIR.
COPY ./foo.sh /app/foo.sh
WORKDIR /dir
RUN chmod +x /app/foo.sh
RUN if [ some_condition ]; then ./foo.sh; fi
Also make sure the script is executable.
After some further investigation:
Using CMD over RUN is not a perfect solution because of the way those commands work. RUN can be used any amount of times, to build Docker image layer by layer, while CMD can be executed only once when the image has been build.
In my case the solution was to:
Open ./foo.sh file with VIM and run: :set fileformat=unix and save the file.
Long story short: the line ending in the shell-script were incorrect and had to be converted to the Unix ones.
I have a shell script, script.sh, that writes some lines to a file:
#!/usr/bin/env bash
printf "blah
blah
blah
blah\n" | sudo tee file.txt
Now in my Dockerfile, I add this script and run it, then attempt to add the generated file.txt:
ADD script.sh .
RUN chmod 755 script.sh && ./script.sh
ADD file.txt .
When I do the above, I just get an error referring to the ADD file.txt . command:
lstat file.txt: no such file or directory
Why can't docker locate the file that my shell script generates?
Where would I be able to find it?
When you RUN chmod 755 script.sh && ./script.sh it actually execute this script inside the docker container (ie: in the docker layer).
When you ADD file.txt . you are trying to add a file from your local filesystem inside the docker container (ie: in a new docker layer).
You can't do that because the file.txt doesn't exist on your computer.
In fact, you already have this file inside docker, try docker run --rm -ti mydockerimage cat file.txt and you should see it's content displayed
It's because Docker load the entire context of the directory (where your Dockerfile is located) to Docker daemon at the beginning. From Docker docs,
The build is run by the Docker daemon, not by the CLI. The first thing a build process does is send the entire context (recursively) to the daemon. In most cases, it’s best to start with an empty directory as context and keep your Dockerfile in that directory. Add only the files needed for building the Dockerfile.
Since your text file was not available at the beginning, you get that error message. If you still want that text file want to be added to Docker image, you can call `docker build' command from the same script file. Modify script.sh,
#!/usr/bin/env bash
printf "blah
blah
blah
blah\n" | sudo tee <docker-file-directory>/file.txt
docker build --tag yourtag <docker-file-directory>
And modify your Dockerfile just to add the generated text file.
ADD file.txt
.. <rest of the Dockerfile instructions>