9

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.)

| improve this question | |
9

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.

| improve this answer | |
  • 2
    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 5 '16 at 9: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 5 '16 at 9: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 5 '16 at 10:14
  • It sets the username passed to the -u argument. You can read the implementation here. – zuazo Jan 5 '16 at 10:36
  • Regarding the problem with your scuba project, see some solutions to the user id problem here: github.com/docker/docker/issues/7198 – zuazo Jan 5 '16 at 11:21
5

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
| improve this answer | |
  • 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 at 8:31

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.