171

[Updated1] I have a shell which will change TCP kernel parameters in some functions, but now I need to make this shell run in Docker container, that means, the shell need to know it is running inside a container and stop configuring the kernel.

Now I'm not sure how to achieve that, here is the contents of /proc/self/cgroup inside the container:

9:hugetlb:/
8:perf_event:/
7:blkio:/
6:freezer:/
5:devices:/
4:memory:/
3:cpuacct:/
2:cpu:/docker/25ef774c390558ad8c4e9a8590b6a1956231aae404d6a7aba4dde320ff569b8b
1:cpuset:/

Any flags above can I use to figure out if this process is running inside a container?

[Updated2]: I have also noticed Determining if a process runs inside lxc/Docker, but it seems not working in this case, the content in /proc/1/cgroup of my container is:

8:perf_event:/
7:blkio:/
6:freezer:/
5:devices:/
4:memory:/
3:cpuacct:/
2:cpu:/docker/25ef774c390558ad8c4e9a8590b6a1956231aae404d6a7aba4dde320ff569b8b
1:cpuset:/

No /lxc/containerid

4
  • 1
    Not a very clear question. Why do you need this? Commented May 7, 2014 at 8:57
  • 2
    Duplicate of stackoverflow.com/questions/20010199/… Commented May 7, 2014 at 21:39
  • @fish no /lxc/<containerid> in my case, see update Commented May 9, 2014 at 3:08
  • 1
    @HenkLangeveld kernel parameters is read-only in Docker container,so I need to know if my shell is running inside containers and disable kernel functions in my shell. see update. Commented May 9, 2014 at 4:31

13 Answers 13

211

Docker creates .dockerenv and .dockerinit (removed in v1.11) files at the top of the container's directory tree so you might want to check if those exist.

Something like this should work.

#!/bin/bash
if [ -f /.dockerenv ]; then
    echo "I'm inside matrix ;(";
else
    echo "I'm living in real world!";
fi
Sign up to request clarification or add additional context in comments.

8 Comments

Unless, of course, you or someone else has created /.dockerinit on your host (perhaps by accident), in which case it will be wrong outside a container.
If somebody else made it in / then they are root and you've got worse problems than knowing whether you are in docker or no.
Beware relying on /.dockerenv in the long term. It is not intended to be used this way.
fwiw, Podman does not create /.dockerenv. It does create /run/.containerenv but by similar logic, sounds like implementation detail not to be relied upon. See github.com/containers/libpod/issues/3586 for some podman-specific alternatives.
@cowlinator Windows containers are even easier, just check HKLM\System\CurrentControlSet\Control\ContainerType, any value means you're in a Windows container.
|
105

To check inside a Docker container if you are inside a Docker container or not can be done via /proc/1/cgroup. As this post suggests you can to the following:

Outside a docker container all entries in /proc/1/cgroup end on / as you can see here:

vagrant@ubuntu-13:~$ cat /proc/1/cgroup
11:name=systemd:/
10:hugetlb:/
9:perf_event:/
8:blkio:/
7:freezer:/
6:devices:/
5:memory:/
4:cpuacct:/
3:cpu:/
2:cpuset:/

Inside a Docker container some of the control groups will belong to Docker (or LXC):

vagrant@ubuntu-13:~$ docker run busybox cat /proc/1/cgroup
11:name=systemd:/
10:hugetlb:/
9:perf_event:/
8:blkio:/
7:freezer:/
6:devices:/docker/3601745b3bd54d9780436faa5f0e4f72bb46231663bb99a6bb892764917832c2
5:memory:/
4:cpuacct:/
3:cpu:/docker/3601745b3bd54d9780436faa5f0e4f72bb46231663bb99a6bb892764917832c2
2:cpuset:/

9 Comments

it is not strictly true that "Outside a docker container all entries in /proc/1/cgroup end on /". On ubuntu 16.04 for example I have: 12:perf_event:/ 11:blkio:/init.scope 10:cpuset:/ 9:devices:/init.scope 8:hugetlb:/ 7:cpu,cpuacct:/init.scope 6:net_cls,net_prio:/ 5:memory:/init.scope 4:pids:/init.scope 3:rdma:/ 2:freezer:/ 1:name=systemd:/init.scope
This pretty much only works on Linux, not on Darwin or other BSDs that don't even use a procfs.
@Christian Docker/LXC are Linux only things, so that's fine, right :)?
pid 1 won't work when container is being started with host's pid namespace ( docker run --pid=host) thus /proc/self/cgroups or /proc/$$/cgroups is better i suppose.
cat /proc/1/cgroup merely outputs 0::/ while in a Docker container. Can anyone tell me what happened?
|
51

Using Environment Variables

For my money, I prefer to set an environment variable inside the docker image that can then be detected by the application.

For example, this is the start of a demo Dockerfile config:

FROM node:12.20.1 as base
ENV DOCKER_RUNNING=true
RUN yarn install --production
RUN yarn build

The second line sets an envar called DOCKER_RUNNING that is then easy to detect. The issue with this is that in a multi-stage build, you will have to repeat the ENV line every time you FROM off of an external image. For example, you can see that I FROM off of node:12.20.1, which includes a lot of extra stuff (git, for example). Later on in my Dockerfile I then COPY things over to a new image based on node:12.20.1-slim, which is much smaller:

FROM node:12.20.1-slim as server
ENV DOCKER_RUNNING=true
EXPOSE 3000
COPY --from=base /build /build
CMD ["node", "server.js"]

Even though this image target server is in the same Dockerfile, it requires the ENV var to be defined again because it has a different base image.

If you make use of Docker-Compose, you could instead easily define an envar there. For example, your docker-compose.yml file could look like this:

version: "3.8"
services:
  nodeserver:
    image: michaeloryl/stackdemo
    environment:
      - NODE_ENV=production
      - DOCKER_RUNNING=true

2 Comments

This is great, just being explicit
Beware that some programs do purge environment when starting (e.g shiny server). The variables are there if you open a shell, but empty within the program. In that case check out how to configure those vars for that particular software.
47

We use the proc's sched (/proc/$PID/sched) to extract the PID of the process. The process's PID inside the container will differ then it's PID on the host (a non-container system).

For example, the output of /proc/1/sched on a container will return:

root@33044d65037c:~# cat /proc/1/sched | head -n 1
bash (5276, #threads: 1)

While on a non-container host:

$ cat /proc/1/sched  | head -n 1
init (1, #threads: 1)

This helps to differentiate if you are in a container or not. eg you can do:

if [[ ! $(cat /proc/1/sched | head -n 1 | grep init) ]]; then {
    echo in docker
} else {
    echo not in docker
} fi

12 Comments

this is actually quite a valuable information. thanks
Depending on the OS, "init" might need to be replaced with "systemd". More information on systemd here.
As mentioned by @BrianV, this doesn't work for me too.
In a Docker container running on a k8s cluster, head -n1 /proc/1/sched returns dumb-init (1, #threads: 1), so the check suggested in this answer fails. (Also, contrary to what the answer suggests, the PID is shown as "1" in that line although I'm doing this in a container.)
This answer is the only one that still works for Docker v20. Simplest code to wrap it (exit code 0 if running with different init than systemd or init: awk '{exit ($1 ~ /^init|systemd$/)}' /proc/1/sched
|
23

Thomas' solution as code:

running_in_docker() {
  (awk -F/ '$2 == "docker"' /proc/self/cgroup | read non_empty_input)
}

Note

The read with a dummy variable is a simple idiom for Does this produce any output?. It's a compact method for turning a possibly verbose grep or awk into a test of a pattern.

Additional note on read

8 Comments

Except...this will fail in some envrionments, because, e.g., 3:cpu,cpuacct:/system.slice/docker-1ce79a0dec4a2084d54acf187a1e177e0339dc90d0218b48b4456576ecaf291e.scope would not match. Simpler to grep -q docker /proc/1/cgroup; the result code from that should also be sufficient.
read might work for bash, but in the most used dash shell you have to use either read dummy (or similar) or use a construct like [ -n "$(command)" ]
@DanielAlder Good catch, Daniel. I will update the text.
Previously this claimed that any Bourne compatible shell supports the plain read without variable name. This is only true for bash and ksh93. The Opengroup only specifies read var and does not mention read behaviour without at least one variable. In bash and ksh93, if no var is given, read uses the shell variable REPLY.
Why can't we just use awk -F: '$3 ~ /docker/' /proc/self/cgroup | read? Works for me.
|
17

What works for me is to check for the inode number of the '/.' Inside the docker, its a very high number. Outside the docker, its a very low number like '2'. I reckon this approach would also depend on the FileSystem being used.

Example

Inside the docker:

# ls -ali / | sed '2!d' |awk {'print $1'}
1565265

Outside the docker

$ ls -ali / | sed '2!d' |awk {'print $1'}
2

In a script:

#!/bin/bash
INODE_NUM=`ls -ali / | sed '2!d' |awk {'print $1'}`
if [ $INODE_NUM == '2' ];
then
        echo "Outside the docker"
else
        echo "Inside the docker"
fi

6 Comments

in MSYS2 ls -ali / | sed '2!d' |awk {'print $1'} 232779805740174872
same as ls -di / ? seems inode num not reliable on different platform
this is the only thing that worked for me to differentiate between a Xen domU host and its docker container
stat -c %i is simpler than ls -ali / | sed '2!d' |awk {'print $1'}
Being inside a chroot returns a different inode number for '/' too but that does not mean I am inside a container
|
4

Based on Dan Walsh's comment about using SELinux ps -eZ | grep container_t, but without requiring ps to be installed:

$ podman run --rm fedora:31 cat /proc/1/attr/current
system_u:system_r:container_t:s0:c56,c299
$ podman run --rm alpine cat /proc/1/attr/current
system_u:system_r:container_t:s0:c558,c813
$ docker run --rm fedora:31 cat /proc/1/attr/current
system_u:system_r:container_t:s0:c8,c583
$ cat /proc/1/attr/current
system_u:system_r:init_t:s0

This just tells you you're running in a container, but not which runtime.

Didn't check other container runtimes but https://opensource.com/article/18/2/understanding-selinux-labels-container-runtimes provides more info and suggests this is widely used, might also work for rkt and lxc?

Comments

4

golang code, via the /proc/%s/cgroup to check a process in a docker, include the k8s cluster

func GetContainerID(pid int32) string {
    cgroupPath := fmt.Sprintf("/proc/%s/cgroup", strconv.Itoa(int(pid)))
    return getContainerID(cgroupPath)
}

func GetImage(containerId string) string {
    if containerId == "" {
        return ""
    }
    image, ok := containerImage[containerId]
    if ok {
        return image
    } else {
        return ""
    }
}
func getContainerID(cgroupPath string) string {
    containerID := ""
    content, err := ioutil.ReadFile(cgroupPath)
    if err != nil {
        return containerID
    }
    lines := strings.Split(string(content), "\n")
    for _, line := range lines {
        field := strings.Split(line, ":")
        if len(field) < 3 {
            continue
        }
        cgroup_path := field[2]
        if len(cgroup_path) < 64 {
            continue
        }
        // Non-systemd Docker
        //5:net_prio,net_cls:/docker/de630f22746b9c06c412858f26ca286c6cdfed086d3b302998aa403d9dcedc42
        //3:net_cls:/kubepods/burstable/pod5f399c1a-f9fc-11e8-bf65-246e9659ebfc/9170559b8aadd07d99978d9460cf8d1c71552f3c64fefc7e9906ab3fb7e18f69
        pos := strings.LastIndex(cgroup_path, "/")
        if pos > 0 {
            id_len := len(cgroup_path) - pos - 1
            if id_len == 64 {
                //p.InDocker = true
                // docker id
                containerID = cgroup_path[pos+1 : pos+1+64]
                // logs.Debug("pid:%v in docker id:%v", pid, id)
                return containerID
            }
        }
        // systemd Docker
        //5:net_cls:/system.slice/docker-afd862d2ed48ef5dc0ce8f1863e4475894e331098c9a512789233ca9ca06fc62.scope
        docker_str := "docker-"
        pos = strings.Index(cgroup_path, docker_str)
        if pos > 0 {
            pos_scope := strings.Index(cgroup_path, ".scope")
            id_len := pos_scope - pos - len(docker_str)
            if pos_scope > 0 && id_len == 64 {
                containerID = cgroup_path[pos+len(docker_str) : pos+len(docker_str)+64]
                return containerID
            }
        }
    }
    return containerID
}

1 Comment

care to explain what the code does? Thank you.
3

We needed to exclude processes running in containers, but instead of checking for just docker cgroups we decided to compare /proc/<pid>/ns/pid to the init system at /proc/1/ns/pid. Example:

pid=$(ps ax | grep "[r]edis-server \*:6379" | awk '{print $1}')
if [ $(readlink "/proc/$pid/ns/pid") == $(readlink /proc/1/ns/pid) ]; then
   echo "pid $pid is the same namespace as init system"
else
   echo "pid $pid is in a different namespace as init system"
fi

Or in our case we wanted a one liner that generates an error if the process is NOT in a container

bash -c "test -h /proc/4129/ns/pid && test $(readlink /proc/4129/ns/pid) != $(readlink /proc/1/ns/pid)"

which we can execute from another process and if the exit code is zero then the specified PID is running in a different namespace.

2 Comments

Does not work for me. From within a k8s-scheduled Docker container, readlink /proc/self/ns/pid and readlink /proc/1/ns/pid produce the same output.
@StefanMajewsky Might want to try using github.com/jessfraz/amicontained to see what features are enabled in the container runtime.
1

What works for me, as long as I know the system programs/scrips will be running on, is confirming if what's running with PID 1 is systemd (or equivalent). If not, that's a container. And this should be true for any linux container, not only docker.

Comments

0

Process with pid 1 will be different between container and host:

  • On Linux host systems it will be systemd or init
  • In Docker container it will be the process that is run by the container, but not systemd or init

Check process name with pid 1

$ ps -p 1 -o comm=

2 Comments

Nope, on docker it frequently should be an init, or very "simpleinit".
The signal handling of many programs doesn't match what is required by the "init" protocol so those programs will shutdown poorly, either not responding to the signals (Until killed hard) or just dropping out without cleanup. In addition not all programs are single process (They can call other programs) and while they should reap their zombies, not all do. That is why programs like "tini" exist at all.
-1

The /.dockerenv file seems to not exist when using GitPod, so I used the following check extra to @at0S's answer:

if [ -f /.dockerenv ] | [ -n "$(env | grep "^GITPOD")" ]; then
  echo "In Docker"
else
  echo "Outside Docker"
fi

Comments

-2

Had the need for this capability in 2022 on macOS and only the answer by @at0S still works from all the other options.

  • /proc/1/cgroup only has the root directory in a container unless configured otherwise
  • /proc/1/sched showed the same in-container process number. The name was different (bash) but that's not very portable.
  • Environment variables work if you configure your container yourself, but none of the default environment variables helped

I did find an option not listed in the other answers: /proc/1/mounts included an overlay filesystem with "docker" in its path.

Comments

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.