24

What are the .dockerenv and .dockerinit files in the root of my container's filesystem? How are they used? Is there any documentation on these files?

root@18ceee4f9041:/# ls -al /
total 72
drwxr-xr-x.  21 root root 4096 Jan  4 20:45 .
drwxr-xr-x.  21 root root 4096 Jan  4 20:45 ..
-rwxr-xr-x.   1 root root    0 Jan  4 20:45 .dockerenv
-rwxr-xr-x.   1 root root    0 Jan  4 20:45 .dockerinit

Other people have asked similar questions, but I can find no answers:

I'm asking because I'm working on a bug in my docker-executing tool called scuba. You can pass --user to docker run to set the UID of the process in a container, but it has no entry in /etc/passwd, so I was investigating options for creating the user during container startup.

(Cross-posted at Stack Overflow, where it may be closed.)

Community
  • 1
Jonathon Reinhart
  • 3,414

2 Answers2

20

AFAIK there is no official documentation about them.

Those files where only used by the old and deprecated LXC execution driver. They were hacks required by docker when using LXC to run the containers.

The .dockerinit was a sort of init process. It was the binary run by the lxc-attach command called when starting a container. It was the responsible to setup the environment, the user and the working directory and then run your entrypoint/cmd.

The .dockerenv contained the environment variables defined inside the container. They were used to setup the environment variables properly after the lxc-attach. This file was read by the .dockerinit process.

The new libcontainer/runc driver (the driver enabled by default) does not use these files. You will find them empty in your containers. In fact, the LXC support has been recently removed from the docker development branch.

So maybe these files will eventually disappear in the future, although currently are widely used by applications to detect the presence of docker.

zuazo
  • 411
  • 3
    A small inaccuracy: According to the source code, they’re mount points, specified in Docker’s core, not specific to the LXC driver. – Daniel B Jan 05 '16 at 09:28
  • 1
    Yes, you are right. Those files are part of a list of mount points created as empty files in the Docker core when creating the root FS. But those two specific files/mountpoints are only used by LXC. – zuazo Jan 05 '16 at 09:49
  • Thank you for this. Could you please see my edit regarding "scuba"? Also, could you elaborate on "It was the responsible to setup... the user" ? This is relevant to my issue. – Jonathon Reinhart Jan 05 '16 at 10:14
  • It sets the username passed to the -u argument. You can read the implementation here. – zuazo Jan 05 '16 at 10:36
  • Regarding the problem with your scuba project, see some solutions to the user id problem here: https://github.com/docker/docker/issues/7198 – zuazo Jan 05 '16 at 11:21
  • 1
    Thanks a lot @zuazo. I ended up working around the issue by creating a user in the container which matches the uid of the invoking user on the host. See JonathonReinhart/scuba#11. – Jonathon Reinhart Jan 05 '16 at 18:22
  • 3
    It comes to 2020 and /.dockerenv still exists in every docker container. – ttimasdf Aug 17 '20 at 12:33
  • @ttimasdf And that's good... I just found out that checking /proc/1/cgroup doesn't work for cgroups V2, and I need a way to know if I'm being run inside docker or not, these empty files are a very simple thing to solve that requirement. – GACy20 Feb 01 '22 at 16:40
10

In order to find out, whether their code is running inside a docker environment, it was popular to test for the existence of either the /.dockerinit or the /.dockerenv file.

Since the dockerinit file has been removed in newer versions, the best idea should now be to check the existence of the dockerenv file.

A sample implementation of such a check from our code:

if ! [ -f /.dockerenv ] ; then
  echo "Not running inside docker, exiting to avoid data damage." >&2
  exit 1
fi
user2291758
  • 201
  • 1
    According to another answer here, testing for .dockerenv is not reliable either. Isn't there a more solid way to test for whether code is inside docker? – jayarjo Apr 30 '20 at 08:31
  • 1
    If you rely on that, why not add your own layer to put it there, in case your base image lacks it? – Ville Laitila Jun 08 '21 at 19:33