Why shell commands CP and CAT don't working in container STARTUP.SH?

General Discussions
1

I can don’t understand this trouble. I have create docker image

FROM XXXXXX/daemon:latest
COPY daemon-startup.sh /shartup.sh
COPY daemon.conf /tmp/daemon.conf
RUN chmod 777 /shartup.sh

both files /shartup.sh and /tmp/daemon.conf present inside imagem I can see it.
However when container started

sudo docker run -it -e RPC_PASSWORD=rpcpassword123456 -p XXX.XX.XX.XX:46003:46003 YYYYY/daemon:latest

I expect that my startup file will be working, I expect CP will be done and expect CAT result in output.

#!/bin/bash
if [ -z $RPC_PASSWORD ]; then
echo “Need to set env RPC_PASSWORD”
exit 1
fi

sed -i “s/{{RPC_PASSWORD}}/$RPC_PASSWORD/g” /tmp/daemon.conf

cat /tmp/daemon.conf
cp /tmp/daemon.conf /root/.daemon/daemon.conf

cat /root/.daemon/daemon.conf
exec daemond -conf=/root/.daemon/daemon.conf

However I don’t see result of CAT in console (only “daemon started”) and If I have start the same image with

sudo docker run -it -e RPC_PASSWORD=rpcpassword123456 -p XXX.XX.XX.XX:46003:46003 YYYYY/daemon:latest ls -la /root/.daemon/

I don’t see daemon.conf config file at all, directory /root/.daemon/ is empty. Why? I’m sorry, I don’t understand.

2

When building images, the content of /tmp will not make it into the image. The folder mounts a disposable tempfs volume, which gets removed. Use a different path and you should be good.

3

It does not seem to be true. I wasn’t sure so I tried and my file remained in /tmp even inside the container. Tried on MacOS and Ubuntu Linux hosts
And also:

:slight_smile: .

@alexev275 Try to add set -eux -o pipefail to your startup script right after #!/bin/bash
It should fail if the files are not there and not instead of starting the daemon.

#!/bin/bash
if [ -z $RPC_PASSWORD ]; then
    echo “Need to set env RPC_PASSWORD”
    exit 1
fi

sed -i “s/{{RPC_PASSWORD}}/$RPC_PASSWORD/g” /tmp/daemon.conf

cat /tmp/daemon.conf
cp /tmp/daemon.conf /root/.daemon/daemon.conf

cat /root/.daemon/daemon.conf
exec daemond -conf=/root/.daemon/daemon.conf

This is for debugging only t see where the script stops. After that you can remove “x” but keep set -eu -o pipefail or at least set -eu

If the image contains the files then it is possible that have an entrypoint which clears the /tmp folder. It could also be caused by mounting an empty volume or using “tmpfs” for your containers any volime or tmpfs definition in your command.

There may be a way that I am not aware of to make /tmp to be on tmpfs by default so run “df” in your container to see if /tmp is on tmpfs. You can lalso try to override the entrypoint when you start the container to check the files:

docker run --rm --entrypoint "" containername ls -l /tmp
4

Hmm, that’s surprising. I had problems in the past because of that behavior. I only use docker where it’s a first class citizen: linux :slight_smile:

update: I check it with a container and you are right: it is not tmpfs, it is just a subfolder in the / fs:

root@c46fad75c477:/# findmnt --target /tmp
TARGET SOURCE  FSTYPE  OPTIONS
/      overlay overlay rw,relatime,lowerdir=/var/lib/docker/overlay2/l/BBQJ4RXPT4T44UX5QL4LFTTGTF:/var/lib/docker/overlay2/l/D2ZL5GVOFPFIBKU2K73GUS

The same test can be done in a Dockerfile as well.

Still, I remember I had problems when I stored data in /tmp while building images. I don’t recall the exact issue as it was 2 years ago.

7

Thank you, without /tmp and with “set -eux -o pipefail” container working fine!