How to determine if a process runs inside lxc/Docker?












125















Is there any way to determine if a process (script) runs inside an lxc container (~ Docker runtime)? I know that some programs are able to detect whether they run inside a virtual machine, is something similar available for lxc/docker?










share|improve this question

























  • It might seem pedantic, but it would be best to rephrase your question to describe a problem you're having and ask how to solve it -- without that, the question stands a higher chance of being closed. In many cases it's difficult to make that change but in yours it wouldn't be hard to simply rephrase if you wish.

    – mah
    Nov 15 '13 at 21:04











  • there is an interesting response when issuing this command while inside a container : uptime

    – Scott Stensland
    Feb 19 '17 at 1:16


















125















Is there any way to determine if a process (script) runs inside an lxc container (~ Docker runtime)? I know that some programs are able to detect whether they run inside a virtual machine, is something similar available for lxc/docker?










share|improve this question

























  • It might seem pedantic, but it would be best to rephrase your question to describe a problem you're having and ask how to solve it -- without that, the question stands a higher chance of being closed. In many cases it's difficult to make that change but in yours it wouldn't be hard to simply rephrase if you wish.

    – mah
    Nov 15 '13 at 21:04











  • there is an interesting response when issuing this command while inside a container : uptime

    – Scott Stensland
    Feb 19 '17 at 1:16
















125












125








125


29






Is there any way to determine if a process (script) runs inside an lxc container (~ Docker runtime)? I know that some programs are able to detect whether they run inside a virtual machine, is something similar available for lxc/docker?










share|improve this question
















Is there any way to determine if a process (script) runs inside an lxc container (~ Docker runtime)? I know that some programs are able to detect whether they run inside a virtual machine, is something similar available for lxc/docker?







linux bash docker






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Apr 7 '18 at 22:40









Ciro Santilli 新疆改造中心 六四事件 法轮功

148k34560475




148k34560475










asked Nov 15 '13 at 20:42









Mate VargaMate Varga

1,0292914




1,0292914













  • It might seem pedantic, but it would be best to rephrase your question to describe a problem you're having and ask how to solve it -- without that, the question stands a higher chance of being closed. In many cases it's difficult to make that change but in yours it wouldn't be hard to simply rephrase if you wish.

    – mah
    Nov 15 '13 at 21:04











  • there is an interesting response when issuing this command while inside a container : uptime

    – Scott Stensland
    Feb 19 '17 at 1:16





















  • It might seem pedantic, but it would be best to rephrase your question to describe a problem you're having and ask how to solve it -- without that, the question stands a higher chance of being closed. In many cases it's difficult to make that change but in yours it wouldn't be hard to simply rephrase if you wish.

    – mah
    Nov 15 '13 at 21:04











  • there is an interesting response when issuing this command while inside a container : uptime

    – Scott Stensland
    Feb 19 '17 at 1:16



















It might seem pedantic, but it would be best to rephrase your question to describe a problem you're having and ask how to solve it -- without that, the question stands a higher chance of being closed. In many cases it's difficult to make that change but in yours it wouldn't be hard to simply rephrase if you wish.

– mah
Nov 15 '13 at 21:04





It might seem pedantic, but it would be best to rephrase your question to describe a problem you're having and ask how to solve it -- without that, the question stands a higher chance of being closed. In many cases it's difficult to make that change but in yours it wouldn't be hard to simply rephrase if you wish.

– mah
Nov 15 '13 at 21:04













there is an interesting response when issuing this command while inside a container : uptime

– Scott Stensland
Feb 19 '17 at 1:16







there is an interesting response when issuing this command while inside a container : uptime

– Scott Stensland
Feb 19 '17 at 1:16














13 Answers
13






active

oldest

votes


















125














The most reliable way is to check /proc/1/cgroup. It will tell you the control groups of the init process, and when you are not in a container, that will be / for all hierarchies. When you are inside a container, you will see the name of the anchor point; which, with LXC/Docker containers, will be something like /lxc/<containerid> or /docker/<containerid> respectively.






share|improve this answer





















  • 12





    docker now uses docker instead of lxc in those paths

    – Andy
    Nov 21 '15 at 16:29






  • 4





    Does not work for lxd/lxc containers, but stackoverflow.com/a/20010626/170230 does.

    – Draco Ater
    Jun 8 '16 at 6:39











  • With later versions of systemd it looks like you can't rely on process 1 using / for all cgroups; on my Debian 9 system (systemd 232) only three of the ten cgroups (3:cpuset, 4:perf_event and 7:freezer) are at root; the rest are under /init.scope. That said, I think that searching that file for :/docker/ is probably the most reliable heuristic at the moment.

    – Curt J. Sampson
    Feb 28 '18 at 7:40








  • 1





    grep 'docker|lxc' /proc/1/cgroup works for me on Docker 18.09.

    – ferkulat
    Feb 1 at 11:04



















129














Docker creates a .dockerenv file at the root of the directory tree inside container.
You can run this script to verify



#!/bin/bash
if [ -f /.dockerenv ]; then
echo "I'm inside matrix ;(";
else
echo "I'm living in real world!";
fi





MORE:
Ubuntu actually has a bash script: /bin/running-in-container and it actually can return the type of container it has been invoked in. Might be helpful.
Don't know about other major distros though.






share|improve this answer





















  • 11





    Important note: the .dockerinit file has been removed in recent versions of Docker, so this method won't work any more. As of this writing, the .dockerenv file is still kept around, so perhaps that could be used instead.

    – Jason R
    Apr 27 '16 at 1:10











  • On Debian /bin/running-in-container is provided by upstart. With the transition to systemd it might go away. I hope not - it sounds useful!

    – Max Murphy
    Sep 1 '16 at 9:12











  • "on top of directory tree", what does that mean? where is that?

    – Alexander Mills
    Dec 20 '16 at 10:18






  • 2





    Others have pointed out that checking .dockerenv is not recommended

    – Dave
    Sep 25 '18 at 10:53











  • For me .dockerenv is more like edge of the world from "13th floor".

    – okutane
    Oct 15 '18 at 10:36



















15














On a new ubuntu 16.04 system, new systemd & lxc 2.0



sudo grep -qa container=lxc /proc/1/environ





share|improve this answer































    12














    A concise way to check for docker in a bash script is:



    #!/bin/bash
    if grep docker /proc/1/cgroup -qa; then
    echo I'm running on docker.
    fi





    share|improve this answer































      9














      Handy Python function to check if running in Docker (linux-only, obvs.):



      def in_docker():
      """ Returns: True if running in a Docker container, else False """
      with open('/proc/1/cgroup', 'rt') as ifh:
      return 'docker' in ifh.read()





      share|improve this answer


























      • Important Note! This does not appear to work when the container is running in kubernetes. Instead, replace the last line with 'kubepod' in place of 'docker'. (Or, put in an "or" statement that checks for both ;))

        – JJC
        Jan 13 at 3:20



















      8














      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.






      share|improve this answer
























      • Depending on the OS, "init" might need to be replaced by "systemd". More information on systemd here.

        – BrianV
        Jun 23 '17 at 1:50













      • Yes, but the point wasn't the name of the init process, the point was the process number.

        – MillerGeek
        May 2 '18 at 14:31











      • This seems to only work on Docker. In an LXC container It's returning Systemd PID 1

        – MillerGeek
        May 2 '18 at 14:32



















      6














      The easiest way would be to check the environment. If you have the container=lxc variable, you are within a container.



      Otherwise, if you are root, you can try to perform mknod or mount operation, if it fails, you are most likely in a container with dropped capabilities.






      share|improve this answer
























      • This one works not only for docker (I didn't check that), but more importantly for lxd/lxc containers (checked), where /proc/1/cgroup does not allow you to detect that.

        – Draco Ater
        Jun 8 '16 at 6:37






      • 5





        Does not work for Docker. The variable is not set.

        – hakre
        Nov 22 '16 at 14:58








      • 2





        can you edit the answer with code instead of pseudocode? "container=lxc" ?is not proper anything. do you mean something like if [[ "lxc" = "$container" ]] ?

        – Alexander Mills
        Dec 20 '16 at 10:20








      • 3





        I mean...it is weird, usually env variables are in all caps, so looking for some precision here

        – Alexander Mills
        Dec 20 '16 at 10:22











      • docker run alpine env does not give anything that looks like that variable

        – Archimedes Trajano
        Mar 10 at 16:01



















      3














      My answer only applies for Node.js processes but may be relevant for some visitors who stumble to this question looking for a Node.js specific answer.



      I had the same problem and relying on /proc/self/cgroup I created an npm package for solely this purpose — to detect whether a Node.js process runs inside a Docker container or not.



      The containerized npm module will help you out in Node.js. It is not currently tested in Io.js but may just as well work there too.






      share|improve this answer
























      • Thanks for this module, seems to be a couple of open fixes pending - are you still maintaining this?

        – stevokk
        Aug 2 '18 at 8:51



















      3














      Check for all the solutions above in Python:



      import os
      import subprocess

      def in_container():
      # type: () -> bool
      """ Determines if we're running in an lxc/docker container. """
      out = subprocess.check_output('cat /proc/1/sched', shell=True)
      out = out.decode('utf-8').lower()
      checks = [
      'docker' in out,
      '/lxc/' in out,
      out.split()[0] not in ('systemd', 'init',),
      os.path.exists('/.dockerenv'),
      os.path.exists('/.dockerinit'),
      os.getenv('container', None) is not None
      ]
      return any(checks)





      share|improve this answer































        2














        Docker is evolving day by day, so we can't say for sure if they are going to keep .dockerenv .dockerinit in the future.



        In most of the Linux flavours init is the first process to start. But in case of containers this is not true.



        #!/bin/bash
        if ps -p1|grep -q init;then
        echo "non-docker"
        else
        echo "docker"
        fi





        share|improve this answer
























        • This doesn't work under MacOS X.

          – Roman Trofimov
          Sep 15 '16 at 10:53






        • 5





          @RomanTrofimov LXC/Docker doesn't either. What a funny comment.

          – abourget
          Mar 3 '17 at 17:41






        • 1





          It does not work in centos 7 as well. When I run in my host machine it says docker. Looks like systemd is running as process id 1

          – Venkateswara Rao
          Jan 26 '18 at 5:02











        • @VenkateswaraRao - This must be run inside the container. The intent is to find out if you are inside a docker container or not.

          – Govind Kailas
          Jan 30 '18 at 4:43






        • 1





          @SamThomas: launchd, upstart, Solaris SMF, systemd, Sys V style init, BSD style init (these two and some others might call their PID 1 init though), OpenRC, initng, runit. See here. Most modern Linux-based systems would use systemd, some older ones, upstart.... All modern OS X systems would use launchd

          – Gert van den Berg
          May 23 '18 at 8:16





















        1














        Building on the accepted answer that tests /proc/*/cgroup ..



        awk -F: '$3 ~ /^/$/ {c=1} END{ exit c }' /proc/self/cgroup


        So for use in a script or so, a test could be constructed this way.



        is_running_in_container() {
        awk -F: '$3 ~ /^/$/{ c=1 } END { exit c }' /proc/self/cgroup
        }

        if is_running_in_container; then
        echo "Aye!! I'm in a container"
        else
        echo "Nay!! I'm not in a container"
        fi





        share|improve this answer































          0














          This SO Q&A: "Find out if the OS is running in a virtual environment"; though not the same as the OP's question, it does indeed answer common cases of finding which container you're in (if at all).



          In particular, install and read the code of this bash script which seems to work pretty well:



          virt-what :



          sudo apt install virt-what





          share|improve this answer


























          • Doesn't work with virt-what version 1.14-1 on Ubuntu 16.04. Needs patch.

            – Lucas
            Jan 4 '18 at 22:23



















          -3














          Maybe this do the trick:



          if [ -z $(docker ps -q) ]; then
          echo "There is not process currently running"
          else
          echo "There are processes running"
          fi


          Is that what you want? Help it help =)






          share|improve this answer



















          • 1





            No docker binary is available from inside of container, obviously.

            – toriningen
            Jul 5 '18 at 17:02






          • 3





            Umm, this would fail in situations (e.g. gitlab docker-in-docker) where the controlling container has docker and access to the hosts' docker socket.

            – shalomb
            Jul 15 '18 at 21:02












          Your Answer






          StackExchange.ifUsing("editor", function () {
          StackExchange.using("externalEditor", function () {
          StackExchange.using("snippets", function () {
          StackExchange.snippets.init();
          });
          });
          }, "code-snippets");

          StackExchange.ready(function() {
          var channelOptions = {
          tags: "".split(" "),
          id: "1"
          };
          initTagRenderer("".split(" "), "".split(" "), channelOptions);

          StackExchange.using("externalEditor", function() {
          // Have to fire editor after snippets, if snippets enabled
          if (StackExchange.settings.snippets.snippetsEnabled) {
          StackExchange.using("snippets", function() {
          createEditor();
          });
          }
          else {
          createEditor();
          }
          });

          function createEditor() {
          StackExchange.prepareEditor({
          heartbeatType: 'answer',
          autoActivateHeartbeat: false,
          convertImagesToLinks: true,
          noModals: true,
          showLowRepImageUploadWarning: true,
          reputationToPostImages: 10,
          bindNavPrevention: true,
          postfix: "",
          imageUploader: {
          brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
          contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
          allowUrls: true
          },
          onDemand: true,
          discardSelector: ".discard-answer"
          ,immediatelyShowMarkdownHelp:true
          });


          }
          });














          draft saved

          draft discarded


















          StackExchange.ready(
          function () {
          StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f20010199%2fhow-to-determine-if-a-process-runs-inside-lxc-docker%23new-answer', 'question_page');
          }
          );

          Post as a guest















          Required, but never shown

























          13 Answers
          13






          active

          oldest

          votes








          13 Answers
          13






          active

          oldest

          votes









          active

          oldest

          votes






          active

          oldest

          votes









          125














          The most reliable way is to check /proc/1/cgroup. It will tell you the control groups of the init process, and when you are not in a container, that will be / for all hierarchies. When you are inside a container, you will see the name of the anchor point; which, with LXC/Docker containers, will be something like /lxc/<containerid> or /docker/<containerid> respectively.






          share|improve this answer





















          • 12





            docker now uses docker instead of lxc in those paths

            – Andy
            Nov 21 '15 at 16:29






          • 4





            Does not work for lxd/lxc containers, but stackoverflow.com/a/20010626/170230 does.

            – Draco Ater
            Jun 8 '16 at 6:39











          • With later versions of systemd it looks like you can't rely on process 1 using / for all cgroups; on my Debian 9 system (systemd 232) only three of the ten cgroups (3:cpuset, 4:perf_event and 7:freezer) are at root; the rest are under /init.scope. That said, I think that searching that file for :/docker/ is probably the most reliable heuristic at the moment.

            – Curt J. Sampson
            Feb 28 '18 at 7:40








          • 1





            grep 'docker|lxc' /proc/1/cgroup works for me on Docker 18.09.

            – ferkulat
            Feb 1 at 11:04
















          125














          The most reliable way is to check /proc/1/cgroup. It will tell you the control groups of the init process, and when you are not in a container, that will be / for all hierarchies. When you are inside a container, you will see the name of the anchor point; which, with LXC/Docker containers, will be something like /lxc/<containerid> or /docker/<containerid> respectively.






          share|improve this answer





















          • 12





            docker now uses docker instead of lxc in those paths

            – Andy
            Nov 21 '15 at 16:29






          • 4





            Does not work for lxd/lxc containers, but stackoverflow.com/a/20010626/170230 does.

            – Draco Ater
            Jun 8 '16 at 6:39











          • With later versions of systemd it looks like you can't rely on process 1 using / for all cgroups; on my Debian 9 system (systemd 232) only three of the ten cgroups (3:cpuset, 4:perf_event and 7:freezer) are at root; the rest are under /init.scope. That said, I think that searching that file for :/docker/ is probably the most reliable heuristic at the moment.

            – Curt J. Sampson
            Feb 28 '18 at 7:40








          • 1





            grep 'docker|lxc' /proc/1/cgroup works for me on Docker 18.09.

            – ferkulat
            Feb 1 at 11:04














          125












          125








          125







          The most reliable way is to check /proc/1/cgroup. It will tell you the control groups of the init process, and when you are not in a container, that will be / for all hierarchies. When you are inside a container, you will see the name of the anchor point; which, with LXC/Docker containers, will be something like /lxc/<containerid> or /docker/<containerid> respectively.






          share|improve this answer















          The most reliable way is to check /proc/1/cgroup. It will tell you the control groups of the init process, and when you are not in a container, that will be / for all hierarchies. When you are inside a container, you will see the name of the anchor point; which, with LXC/Docker containers, will be something like /lxc/<containerid> or /docker/<containerid> respectively.







          share|improve this answer














          share|improve this answer



          share|improve this answer








          edited Jul 4 '17 at 10:33









          user2064000

          1,35121838




          1,35121838










          answered Nov 15 '13 at 23:36









          jpetazzojpetazzo

          10.2k23040




          10.2k23040








          • 12





            docker now uses docker instead of lxc in those paths

            – Andy
            Nov 21 '15 at 16:29






          • 4





            Does not work for lxd/lxc containers, but stackoverflow.com/a/20010626/170230 does.

            – Draco Ater
            Jun 8 '16 at 6:39











          • With later versions of systemd it looks like you can't rely on process 1 using / for all cgroups; on my Debian 9 system (systemd 232) only three of the ten cgroups (3:cpuset, 4:perf_event and 7:freezer) are at root; the rest are under /init.scope. That said, I think that searching that file for :/docker/ is probably the most reliable heuristic at the moment.

            – Curt J. Sampson
            Feb 28 '18 at 7:40








          • 1





            grep 'docker|lxc' /proc/1/cgroup works for me on Docker 18.09.

            – ferkulat
            Feb 1 at 11:04














          • 12





            docker now uses docker instead of lxc in those paths

            – Andy
            Nov 21 '15 at 16:29






          • 4





            Does not work for lxd/lxc containers, but stackoverflow.com/a/20010626/170230 does.

            – Draco Ater
            Jun 8 '16 at 6:39











          • With later versions of systemd it looks like you can't rely on process 1 using / for all cgroups; on my Debian 9 system (systemd 232) only three of the ten cgroups (3:cpuset, 4:perf_event and 7:freezer) are at root; the rest are under /init.scope. That said, I think that searching that file for :/docker/ is probably the most reliable heuristic at the moment.

            – Curt J. Sampson
            Feb 28 '18 at 7:40








          • 1





            grep 'docker|lxc' /proc/1/cgroup works for me on Docker 18.09.

            – ferkulat
            Feb 1 at 11:04








          12




          12





          docker now uses docker instead of lxc in those paths

          – Andy
          Nov 21 '15 at 16:29





          docker now uses docker instead of lxc in those paths

          – Andy
          Nov 21 '15 at 16:29




          4




          4





          Does not work for lxd/lxc containers, but stackoverflow.com/a/20010626/170230 does.

          – Draco Ater
          Jun 8 '16 at 6:39





          Does not work for lxd/lxc containers, but stackoverflow.com/a/20010626/170230 does.

          – Draco Ater
          Jun 8 '16 at 6:39













          With later versions of systemd it looks like you can't rely on process 1 using / for all cgroups; on my Debian 9 system (systemd 232) only three of the ten cgroups (3:cpuset, 4:perf_event and 7:freezer) are at root; the rest are under /init.scope. That said, I think that searching that file for :/docker/ is probably the most reliable heuristic at the moment.

          – Curt J. Sampson
          Feb 28 '18 at 7:40







          With later versions of systemd it looks like you can't rely on process 1 using / for all cgroups; on my Debian 9 system (systemd 232) only three of the ten cgroups (3:cpuset, 4:perf_event and 7:freezer) are at root; the rest are under /init.scope. That said, I think that searching that file for :/docker/ is probably the most reliable heuristic at the moment.

          – Curt J. Sampson
          Feb 28 '18 at 7:40






          1




          1





          grep 'docker|lxc' /proc/1/cgroup works for me on Docker 18.09.

          – ferkulat
          Feb 1 at 11:04





          grep 'docker|lxc' /proc/1/cgroup works for me on Docker 18.09.

          – ferkulat
          Feb 1 at 11:04













          129














          Docker creates a .dockerenv file at the root of the directory tree inside container.
          You can run this script to verify



          #!/bin/bash
          if [ -f /.dockerenv ]; then
          echo "I'm inside matrix ;(";
          else
          echo "I'm living in real world!";
          fi





          MORE:
          Ubuntu actually has a bash script: /bin/running-in-container and it actually can return the type of container it has been invoked in. Might be helpful.
          Don't know about other major distros though.






          share|improve this answer





















          • 11





            Important note: the .dockerinit file has been removed in recent versions of Docker, so this method won't work any more. As of this writing, the .dockerenv file is still kept around, so perhaps that could be used instead.

            – Jason R
            Apr 27 '16 at 1:10











          • On Debian /bin/running-in-container is provided by upstart. With the transition to systemd it might go away. I hope not - it sounds useful!

            – Max Murphy
            Sep 1 '16 at 9:12











          • "on top of directory tree", what does that mean? where is that?

            – Alexander Mills
            Dec 20 '16 at 10:18






          • 2





            Others have pointed out that checking .dockerenv is not recommended

            – Dave
            Sep 25 '18 at 10:53











          • For me .dockerenv is more like edge of the world from "13th floor".

            – okutane
            Oct 15 '18 at 10:36
















          129














          Docker creates a .dockerenv file at the root of the directory tree inside container.
          You can run this script to verify



          #!/bin/bash
          if [ -f /.dockerenv ]; then
          echo "I'm inside matrix ;(";
          else
          echo "I'm living in real world!";
          fi





          MORE:
          Ubuntu actually has a bash script: /bin/running-in-container and it actually can return the type of container it has been invoked in. Might be helpful.
          Don't know about other major distros though.






          share|improve this answer





















          • 11





            Important note: the .dockerinit file has been removed in recent versions of Docker, so this method won't work any more. As of this writing, the .dockerenv file is still kept around, so perhaps that could be used instead.

            – Jason R
            Apr 27 '16 at 1:10











          • On Debian /bin/running-in-container is provided by upstart. With the transition to systemd it might go away. I hope not - it sounds useful!

            – Max Murphy
            Sep 1 '16 at 9:12











          • "on top of directory tree", what does that mean? where is that?

            – Alexander Mills
            Dec 20 '16 at 10:18






          • 2





            Others have pointed out that checking .dockerenv is not recommended

            – Dave
            Sep 25 '18 at 10:53











          • For me .dockerenv is more like edge of the world from "13th floor".

            – okutane
            Oct 15 '18 at 10:36














          129












          129








          129







          Docker creates a .dockerenv file at the root of the directory tree inside container.
          You can run this script to verify



          #!/bin/bash
          if [ -f /.dockerenv ]; then
          echo "I'm inside matrix ;(";
          else
          echo "I'm living in real world!";
          fi





          MORE:
          Ubuntu actually has a bash script: /bin/running-in-container and it actually can return the type of container it has been invoked in. Might be helpful.
          Don't know about other major distros though.






          share|improve this answer















          Docker creates a .dockerenv file at the root of the directory tree inside container.
          You can run this script to verify



          #!/bin/bash
          if [ -f /.dockerenv ]; then
          echo "I'm inside matrix ;(";
          else
          echo "I'm living in real world!";
          fi





          MORE:
          Ubuntu actually has a bash script: /bin/running-in-container and it actually can return the type of container it has been invoked in. Might be helpful.
          Don't know about other major distros though.







          share|improve this answer














          share|improve this answer



          share|improve this answer








          edited Jan 7 '17 at 17:40









          James Beninger

          1,83511522




          1,83511522










          answered Aug 27 '14 at 3:09









          at0Sat0S

          2,1511115




          2,1511115








          • 11





            Important note: the .dockerinit file has been removed in recent versions of Docker, so this method won't work any more. As of this writing, the .dockerenv file is still kept around, so perhaps that could be used instead.

            – Jason R
            Apr 27 '16 at 1:10











          • On Debian /bin/running-in-container is provided by upstart. With the transition to systemd it might go away. I hope not - it sounds useful!

            – Max Murphy
            Sep 1 '16 at 9:12











          • "on top of directory tree", what does that mean? where is that?

            – Alexander Mills
            Dec 20 '16 at 10:18






          • 2





            Others have pointed out that checking .dockerenv is not recommended

            – Dave
            Sep 25 '18 at 10:53











          • For me .dockerenv is more like edge of the world from "13th floor".

            – okutane
            Oct 15 '18 at 10:36














          • 11





            Important note: the .dockerinit file has been removed in recent versions of Docker, so this method won't work any more. As of this writing, the .dockerenv file is still kept around, so perhaps that could be used instead.

            – Jason R
            Apr 27 '16 at 1:10











          • On Debian /bin/running-in-container is provided by upstart. With the transition to systemd it might go away. I hope not - it sounds useful!

            – Max Murphy
            Sep 1 '16 at 9:12











          • "on top of directory tree", what does that mean? where is that?

            – Alexander Mills
            Dec 20 '16 at 10:18






          • 2





            Others have pointed out that checking .dockerenv is not recommended

            – Dave
            Sep 25 '18 at 10:53











          • For me .dockerenv is more like edge of the world from "13th floor".

            – okutane
            Oct 15 '18 at 10:36








          11




          11





          Important note: the .dockerinit file has been removed in recent versions of Docker, so this method won't work any more. As of this writing, the .dockerenv file is still kept around, so perhaps that could be used instead.

          – Jason R
          Apr 27 '16 at 1:10





          Important note: the .dockerinit file has been removed in recent versions of Docker, so this method won't work any more. As of this writing, the .dockerenv file is still kept around, so perhaps that could be used instead.

          – Jason R
          Apr 27 '16 at 1:10













          On Debian /bin/running-in-container is provided by upstart. With the transition to systemd it might go away. I hope not - it sounds useful!

          – Max Murphy
          Sep 1 '16 at 9:12





          On Debian /bin/running-in-container is provided by upstart. With the transition to systemd it might go away. I hope not - it sounds useful!

          – Max Murphy
          Sep 1 '16 at 9:12













          "on top of directory tree", what does that mean? where is that?

          – Alexander Mills
          Dec 20 '16 at 10:18





          "on top of directory tree", what does that mean? where is that?

          – Alexander Mills
          Dec 20 '16 at 10:18




          2




          2





          Others have pointed out that checking .dockerenv is not recommended

          – Dave
          Sep 25 '18 at 10:53





          Others have pointed out that checking .dockerenv is not recommended

          – Dave
          Sep 25 '18 at 10:53













          For me .dockerenv is more like edge of the world from "13th floor".

          – okutane
          Oct 15 '18 at 10:36





          For me .dockerenv is more like edge of the world from "13th floor".

          – okutane
          Oct 15 '18 at 10:36











          15














          On a new ubuntu 16.04 system, new systemd & lxc 2.0



          sudo grep -qa container=lxc /proc/1/environ





          share|improve this answer




























            15














            On a new ubuntu 16.04 system, new systemd & lxc 2.0



            sudo grep -qa container=lxc /proc/1/environ





            share|improve this answer


























              15












              15








              15







              On a new ubuntu 16.04 system, new systemd & lxc 2.0



              sudo grep -qa container=lxc /proc/1/environ





              share|improve this answer













              On a new ubuntu 16.04 system, new systemd & lxc 2.0



              sudo grep -qa container=lxc /proc/1/environ






              share|improve this answer












              share|improve this answer



              share|improve this answer










              answered Mar 2 '16 at 15:12









              larsslarss

              15112




              15112























                  12














                  A concise way to check for docker in a bash script is:



                  #!/bin/bash
                  if grep docker /proc/1/cgroup -qa; then
                  echo I'm running on docker.
                  fi





                  share|improve this answer




























                    12














                    A concise way to check for docker in a bash script is:



                    #!/bin/bash
                    if grep docker /proc/1/cgroup -qa; then
                    echo I'm running on docker.
                    fi





                    share|improve this answer


























                      12












                      12








                      12







                      A concise way to check for docker in a bash script is:



                      #!/bin/bash
                      if grep docker /proc/1/cgroup -qa; then
                      echo I'm running on docker.
                      fi





                      share|improve this answer













                      A concise way to check for docker in a bash script is:



                      #!/bin/bash
                      if grep docker /proc/1/cgroup -qa; then
                      echo I'm running on docker.
                      fi






                      share|improve this answer












                      share|improve this answer



                      share|improve this answer










                      answered Jan 10 '17 at 1:40









                      oNaiPsoNaiPs

                      183110




                      183110























                          9














                          Handy Python function to check if running in Docker (linux-only, obvs.):



                          def in_docker():
                          """ Returns: True if running in a Docker container, else False """
                          with open('/proc/1/cgroup', 'rt') as ifh:
                          return 'docker' in ifh.read()





                          share|improve this answer


























                          • Important Note! This does not appear to work when the container is running in kubernetes. Instead, replace the last line with 'kubepod' in place of 'docker'. (Or, put in an "or" statement that checks for both ;))

                            – JJC
                            Jan 13 at 3:20
















                          9














                          Handy Python function to check if running in Docker (linux-only, obvs.):



                          def in_docker():
                          """ Returns: True if running in a Docker container, else False """
                          with open('/proc/1/cgroup', 'rt') as ifh:
                          return 'docker' in ifh.read()





                          share|improve this answer


























                          • Important Note! This does not appear to work when the container is running in kubernetes. Instead, replace the last line with 'kubepod' in place of 'docker'. (Or, put in an "or" statement that checks for both ;))

                            – JJC
                            Jan 13 at 3:20














                          9












                          9








                          9







                          Handy Python function to check if running in Docker (linux-only, obvs.):



                          def in_docker():
                          """ Returns: True if running in a Docker container, else False """
                          with open('/proc/1/cgroup', 'rt') as ifh:
                          return 'docker' in ifh.read()





                          share|improve this answer















                          Handy Python function to check if running in Docker (linux-only, obvs.):



                          def in_docker():
                          """ Returns: True if running in a Docker container, else False """
                          with open('/proc/1/cgroup', 'rt') as ifh:
                          return 'docker' in ifh.read()






                          share|improve this answer














                          share|improve this answer



                          share|improve this answer








                          edited Jan 12 '18 at 0:19









                          Nuno André

                          1,3311223




                          1,3311223










                          answered Mar 8 '17 at 15:09









                          JJCJJC

                          3,61442838




                          3,61442838













                          • Important Note! This does not appear to work when the container is running in kubernetes. Instead, replace the last line with 'kubepod' in place of 'docker'. (Or, put in an "or" statement that checks for both ;))

                            – JJC
                            Jan 13 at 3:20



















                          • Important Note! This does not appear to work when the container is running in kubernetes. Instead, replace the last line with 'kubepod' in place of 'docker'. (Or, put in an "or" statement that checks for both ;))

                            – JJC
                            Jan 13 at 3:20

















                          Important Note! This does not appear to work when the container is running in kubernetes. Instead, replace the last line with 'kubepod' in place of 'docker'. (Or, put in an "or" statement that checks for both ;))

                          – JJC
                          Jan 13 at 3:20





                          Important Note! This does not appear to work when the container is running in kubernetes. Instead, replace the last line with 'kubepod' in place of 'docker'. (Or, put in an "or" statement that checks for both ;))

                          – JJC
                          Jan 13 at 3:20











                          8














                          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.






                          share|improve this answer
























                          • Depending on the OS, "init" might need to be replaced by "systemd". More information on systemd here.

                            – BrianV
                            Jun 23 '17 at 1:50













                          • Yes, but the point wasn't the name of the init process, the point was the process number.

                            – MillerGeek
                            May 2 '18 at 14:31











                          • This seems to only work on Docker. In an LXC container It's returning Systemd PID 1

                            – MillerGeek
                            May 2 '18 at 14:32
















                          8














                          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.






                          share|improve this answer
























                          • Depending on the OS, "init" might need to be replaced by "systemd". More information on systemd here.

                            – BrianV
                            Jun 23 '17 at 1:50













                          • Yes, but the point wasn't the name of the init process, the point was the process number.

                            – MillerGeek
                            May 2 '18 at 14:31











                          • This seems to only work on Docker. In an LXC container It's returning Systemd PID 1

                            – MillerGeek
                            May 2 '18 at 14:32














                          8












                          8








                          8







                          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.






                          share|improve this answer













                          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.







                          share|improve this answer












                          share|improve this answer



                          share|improve this answer










                          answered May 4 '16 at 0:00









                          FounderFounder

                          29935




                          29935













                          • Depending on the OS, "init" might need to be replaced by "systemd". More information on systemd here.

                            – BrianV
                            Jun 23 '17 at 1:50













                          • Yes, but the point wasn't the name of the init process, the point was the process number.

                            – MillerGeek
                            May 2 '18 at 14:31











                          • This seems to only work on Docker. In an LXC container It's returning Systemd PID 1

                            – MillerGeek
                            May 2 '18 at 14:32



















                          • Depending on the OS, "init" might need to be replaced by "systemd". More information on systemd here.

                            – BrianV
                            Jun 23 '17 at 1:50













                          • Yes, but the point wasn't the name of the init process, the point was the process number.

                            – MillerGeek
                            May 2 '18 at 14:31











                          • This seems to only work on Docker. In an LXC container It's returning Systemd PID 1

                            – MillerGeek
                            May 2 '18 at 14:32

















                          Depending on the OS, "init" might need to be replaced by "systemd". More information on systemd here.

                          – BrianV
                          Jun 23 '17 at 1:50







                          Depending on the OS, "init" might need to be replaced by "systemd". More information on systemd here.

                          – BrianV
                          Jun 23 '17 at 1:50















                          Yes, but the point wasn't the name of the init process, the point was the process number.

                          – MillerGeek
                          May 2 '18 at 14:31





                          Yes, but the point wasn't the name of the init process, the point was the process number.

                          – MillerGeek
                          May 2 '18 at 14:31













                          This seems to only work on Docker. In an LXC container It's returning Systemd PID 1

                          – MillerGeek
                          May 2 '18 at 14:32





                          This seems to only work on Docker. In an LXC container It's returning Systemd PID 1

                          – MillerGeek
                          May 2 '18 at 14:32











                          6














                          The easiest way would be to check the environment. If you have the container=lxc variable, you are within a container.



                          Otherwise, if you are root, you can try to perform mknod or mount operation, if it fails, you are most likely in a container with dropped capabilities.






                          share|improve this answer
























                          • This one works not only for docker (I didn't check that), but more importantly for lxd/lxc containers (checked), where /proc/1/cgroup does not allow you to detect that.

                            – Draco Ater
                            Jun 8 '16 at 6:37






                          • 5





                            Does not work for Docker. The variable is not set.

                            – hakre
                            Nov 22 '16 at 14:58








                          • 2





                            can you edit the answer with code instead of pseudocode? "container=lxc" ?is not proper anything. do you mean something like if [[ "lxc" = "$container" ]] ?

                            – Alexander Mills
                            Dec 20 '16 at 10:20








                          • 3





                            I mean...it is weird, usually env variables are in all caps, so looking for some precision here

                            – Alexander Mills
                            Dec 20 '16 at 10:22











                          • docker run alpine env does not give anything that looks like that variable

                            – Archimedes Trajano
                            Mar 10 at 16:01
















                          6














                          The easiest way would be to check the environment. If you have the container=lxc variable, you are within a container.



                          Otherwise, if you are root, you can try to perform mknod or mount operation, if it fails, you are most likely in a container with dropped capabilities.






                          share|improve this answer
























                          • This one works not only for docker (I didn't check that), but more importantly for lxd/lxc containers (checked), where /proc/1/cgroup does not allow you to detect that.

                            – Draco Ater
                            Jun 8 '16 at 6:37






                          • 5





                            Does not work for Docker. The variable is not set.

                            – hakre
                            Nov 22 '16 at 14:58








                          • 2





                            can you edit the answer with code instead of pseudocode? "container=lxc" ?is not proper anything. do you mean something like if [[ "lxc" = "$container" ]] ?

                            – Alexander Mills
                            Dec 20 '16 at 10:20








                          • 3





                            I mean...it is weird, usually env variables are in all caps, so looking for some precision here

                            – Alexander Mills
                            Dec 20 '16 at 10:22











                          • docker run alpine env does not give anything that looks like that variable

                            – Archimedes Trajano
                            Mar 10 at 16:01














                          6












                          6








                          6







                          The easiest way would be to check the environment. If you have the container=lxc variable, you are within a container.



                          Otherwise, if you are root, you can try to perform mknod or mount operation, if it fails, you are most likely in a container with dropped capabilities.






                          share|improve this answer













                          The easiest way would be to check the environment. If you have the container=lxc variable, you are within a container.



                          Otherwise, if you are root, you can try to perform mknod or mount operation, if it fails, you are most likely in a container with dropped capabilities.







                          share|improve this answer












                          share|improve this answer



                          share|improve this answer










                          answered Nov 15 '13 at 21:09









                          creackcreack

                          70.2k107263




                          70.2k107263













                          • This one works not only for docker (I didn't check that), but more importantly for lxd/lxc containers (checked), where /proc/1/cgroup does not allow you to detect that.

                            – Draco Ater
                            Jun 8 '16 at 6:37






                          • 5





                            Does not work for Docker. The variable is not set.

                            – hakre
                            Nov 22 '16 at 14:58








                          • 2





                            can you edit the answer with code instead of pseudocode? "container=lxc" ?is not proper anything. do you mean something like if [[ "lxc" = "$container" ]] ?

                            – Alexander Mills
                            Dec 20 '16 at 10:20








                          • 3





                            I mean...it is weird, usually env variables are in all caps, so looking for some precision here

                            – Alexander Mills
                            Dec 20 '16 at 10:22











                          • docker run alpine env does not give anything that looks like that variable

                            – Archimedes Trajano
                            Mar 10 at 16:01



















                          • This one works not only for docker (I didn't check that), but more importantly for lxd/lxc containers (checked), where /proc/1/cgroup does not allow you to detect that.

                            – Draco Ater
                            Jun 8 '16 at 6:37






                          • 5





                            Does not work for Docker. The variable is not set.

                            – hakre
                            Nov 22 '16 at 14:58








                          • 2





                            can you edit the answer with code instead of pseudocode? "container=lxc" ?is not proper anything. do you mean something like if [[ "lxc" = "$container" ]] ?

                            – Alexander Mills
                            Dec 20 '16 at 10:20








                          • 3





                            I mean...it is weird, usually env variables are in all caps, so looking for some precision here

                            – Alexander Mills
                            Dec 20 '16 at 10:22











                          • docker run alpine env does not give anything that looks like that variable

                            – Archimedes Trajano
                            Mar 10 at 16:01

















                          This one works not only for docker (I didn't check that), but more importantly for lxd/lxc containers (checked), where /proc/1/cgroup does not allow you to detect that.

                          – Draco Ater
                          Jun 8 '16 at 6:37





                          This one works not only for docker (I didn't check that), but more importantly for lxd/lxc containers (checked), where /proc/1/cgroup does not allow you to detect that.

                          – Draco Ater
                          Jun 8 '16 at 6:37




                          5




                          5





                          Does not work for Docker. The variable is not set.

                          – hakre
                          Nov 22 '16 at 14:58







                          Does not work for Docker. The variable is not set.

                          – hakre
                          Nov 22 '16 at 14:58






                          2




                          2





                          can you edit the answer with code instead of pseudocode? "container=lxc" ?is not proper anything. do you mean something like if [[ "lxc" = "$container" ]] ?

                          – Alexander Mills
                          Dec 20 '16 at 10:20







                          can you edit the answer with code instead of pseudocode? "container=lxc" ?is not proper anything. do you mean something like if [[ "lxc" = "$container" ]] ?

                          – Alexander Mills
                          Dec 20 '16 at 10:20






                          3




                          3





                          I mean...it is weird, usually env variables are in all caps, so looking for some precision here

                          – Alexander Mills
                          Dec 20 '16 at 10:22





                          I mean...it is weird, usually env variables are in all caps, so looking for some precision here

                          – Alexander Mills
                          Dec 20 '16 at 10:22













                          docker run alpine env does not give anything that looks like that variable

                          – Archimedes Trajano
                          Mar 10 at 16:01





                          docker run alpine env does not give anything that looks like that variable

                          – Archimedes Trajano
                          Mar 10 at 16:01











                          3














                          My answer only applies for Node.js processes but may be relevant for some visitors who stumble to this question looking for a Node.js specific answer.



                          I had the same problem and relying on /proc/self/cgroup I created an npm package for solely this purpose — to detect whether a Node.js process runs inside a Docker container or not.



                          The containerized npm module will help you out in Node.js. It is not currently tested in Io.js but may just as well work there too.






                          share|improve this answer
























                          • Thanks for this module, seems to be a couple of open fixes pending - are you still maintaining this?

                            – stevokk
                            Aug 2 '18 at 8:51
















                          3














                          My answer only applies for Node.js processes but may be relevant for some visitors who stumble to this question looking for a Node.js specific answer.



                          I had the same problem and relying on /proc/self/cgroup I created an npm package for solely this purpose — to detect whether a Node.js process runs inside a Docker container or not.



                          The containerized npm module will help you out in Node.js. It is not currently tested in Io.js but may just as well work there too.






                          share|improve this answer
























                          • Thanks for this module, seems to be a couple of open fixes pending - are you still maintaining this?

                            – stevokk
                            Aug 2 '18 at 8:51














                          3












                          3








                          3







                          My answer only applies for Node.js processes but may be relevant for some visitors who stumble to this question looking for a Node.js specific answer.



                          I had the same problem and relying on /proc/self/cgroup I created an npm package for solely this purpose — to detect whether a Node.js process runs inside a Docker container or not.



                          The containerized npm module will help you out in Node.js. It is not currently tested in Io.js but may just as well work there too.






                          share|improve this answer













                          My answer only applies for Node.js processes but may be relevant for some visitors who stumble to this question looking for a Node.js specific answer.



                          I had the same problem and relying on /proc/self/cgroup I created an npm package for solely this purpose — to detect whether a Node.js process runs inside a Docker container or not.



                          The containerized npm module will help you out in Node.js. It is not currently tested in Io.js but may just as well work there too.







                          share|improve this answer












                          share|improve this answer



                          share|improve this answer










                          answered Sep 23 '15 at 23:05









                          Martin TajurMartin Tajur

                          1,88911513




                          1,88911513













                          • Thanks for this module, seems to be a couple of open fixes pending - are you still maintaining this?

                            – stevokk
                            Aug 2 '18 at 8:51



















                          • Thanks for this module, seems to be a couple of open fixes pending - are you still maintaining this?

                            – stevokk
                            Aug 2 '18 at 8:51

















                          Thanks for this module, seems to be a couple of open fixes pending - are you still maintaining this?

                          – stevokk
                          Aug 2 '18 at 8:51





                          Thanks for this module, seems to be a couple of open fixes pending - are you still maintaining this?

                          – stevokk
                          Aug 2 '18 at 8:51











                          3














                          Check for all the solutions above in Python:



                          import os
                          import subprocess

                          def in_container():
                          # type: () -> bool
                          """ Determines if we're running in an lxc/docker container. """
                          out = subprocess.check_output('cat /proc/1/sched', shell=True)
                          out = out.decode('utf-8').lower()
                          checks = [
                          'docker' in out,
                          '/lxc/' in out,
                          out.split()[0] not in ('systemd', 'init',),
                          os.path.exists('/.dockerenv'),
                          os.path.exists('/.dockerinit'),
                          os.getenv('container', None) is not None
                          ]
                          return any(checks)





                          share|improve this answer




























                            3














                            Check for all the solutions above in Python:



                            import os
                            import subprocess

                            def in_container():
                            # type: () -> bool
                            """ Determines if we're running in an lxc/docker container. """
                            out = subprocess.check_output('cat /proc/1/sched', shell=True)
                            out = out.decode('utf-8').lower()
                            checks = [
                            'docker' in out,
                            '/lxc/' in out,
                            out.split()[0] not in ('systemd', 'init',),
                            os.path.exists('/.dockerenv'),
                            os.path.exists('/.dockerinit'),
                            os.getenv('container', None) is not None
                            ]
                            return any(checks)





                            share|improve this answer


























                              3












                              3








                              3







                              Check for all the solutions above in Python:



                              import os
                              import subprocess

                              def in_container():
                              # type: () -> bool
                              """ Determines if we're running in an lxc/docker container. """
                              out = subprocess.check_output('cat /proc/1/sched', shell=True)
                              out = out.decode('utf-8').lower()
                              checks = [
                              'docker' in out,
                              '/lxc/' in out,
                              out.split()[0] not in ('systemd', 'init',),
                              os.path.exists('/.dockerenv'),
                              os.path.exists('/.dockerinit'),
                              os.getenv('container', None) is not None
                              ]
                              return any(checks)





                              share|improve this answer













                              Check for all the solutions above in Python:



                              import os
                              import subprocess

                              def in_container():
                              # type: () -> bool
                              """ Determines if we're running in an lxc/docker container. """
                              out = subprocess.check_output('cat /proc/1/sched', shell=True)
                              out = out.decode('utf-8').lower()
                              checks = [
                              'docker' in out,
                              '/lxc/' in out,
                              out.split()[0] not in ('systemd', 'init',),
                              os.path.exists('/.dockerenv'),
                              os.path.exists('/.dockerinit'),
                              os.getenv('container', None) is not None
                              ]
                              return any(checks)






                              share|improve this answer












                              share|improve this answer



                              share|improve this answer










                              answered Sep 26 '17 at 22:54









                              blakevblakev

                              2,23311641




                              2,23311641























                                  2














                                  Docker is evolving day by day, so we can't say for sure if they are going to keep .dockerenv .dockerinit in the future.



                                  In most of the Linux flavours init is the first process to start. But in case of containers this is not true.



                                  #!/bin/bash
                                  if ps -p1|grep -q init;then
                                  echo "non-docker"
                                  else
                                  echo "docker"
                                  fi





                                  share|improve this answer
























                                  • This doesn't work under MacOS X.

                                    – Roman Trofimov
                                    Sep 15 '16 at 10:53






                                  • 5





                                    @RomanTrofimov LXC/Docker doesn't either. What a funny comment.

                                    – abourget
                                    Mar 3 '17 at 17:41






                                  • 1





                                    It does not work in centos 7 as well. When I run in my host machine it says docker. Looks like systemd is running as process id 1

                                    – Venkateswara Rao
                                    Jan 26 '18 at 5:02











                                  • @VenkateswaraRao - This must be run inside the container. The intent is to find out if you are inside a docker container or not.

                                    – Govind Kailas
                                    Jan 30 '18 at 4:43






                                  • 1





                                    @SamThomas: launchd, upstart, Solaris SMF, systemd, Sys V style init, BSD style init (these two and some others might call their PID 1 init though), OpenRC, initng, runit. See here. Most modern Linux-based systems would use systemd, some older ones, upstart.... All modern OS X systems would use launchd

                                    – Gert van den Berg
                                    May 23 '18 at 8:16


















                                  2














                                  Docker is evolving day by day, so we can't say for sure if they are going to keep .dockerenv .dockerinit in the future.



                                  In most of the Linux flavours init is the first process to start. But in case of containers this is not true.



                                  #!/bin/bash
                                  if ps -p1|grep -q init;then
                                  echo "non-docker"
                                  else
                                  echo "docker"
                                  fi





                                  share|improve this answer
























                                  • This doesn't work under MacOS X.

                                    – Roman Trofimov
                                    Sep 15 '16 at 10:53






                                  • 5





                                    @RomanTrofimov LXC/Docker doesn't either. What a funny comment.

                                    – abourget
                                    Mar 3 '17 at 17:41






                                  • 1





                                    It does not work in centos 7 as well. When I run in my host machine it says docker. Looks like systemd is running as process id 1

                                    – Venkateswara Rao
                                    Jan 26 '18 at 5:02











                                  • @VenkateswaraRao - This must be run inside the container. The intent is to find out if you are inside a docker container or not.

                                    – Govind Kailas
                                    Jan 30 '18 at 4:43






                                  • 1





                                    @SamThomas: launchd, upstart, Solaris SMF, systemd, Sys V style init, BSD style init (these two and some others might call their PID 1 init though), OpenRC, initng, runit. See here. Most modern Linux-based systems would use systemd, some older ones, upstart.... All modern OS X systems would use launchd

                                    – Gert van den Berg
                                    May 23 '18 at 8:16
















                                  2












                                  2








                                  2







                                  Docker is evolving day by day, so we can't say for sure if they are going to keep .dockerenv .dockerinit in the future.



                                  In most of the Linux flavours init is the first process to start. But in case of containers this is not true.



                                  #!/bin/bash
                                  if ps -p1|grep -q init;then
                                  echo "non-docker"
                                  else
                                  echo "docker"
                                  fi





                                  share|improve this answer













                                  Docker is evolving day by day, so we can't say for sure if they are going to keep .dockerenv .dockerinit in the future.



                                  In most of the Linux flavours init is the first process to start. But in case of containers this is not true.



                                  #!/bin/bash
                                  if ps -p1|grep -q init;then
                                  echo "non-docker"
                                  else
                                  echo "docker"
                                  fi






                                  share|improve this answer












                                  share|improve this answer



                                  share|improve this answer










                                  answered May 11 '16 at 3:36









                                  Govind KailasGovind Kailas

                                  85141221




                                  85141221













                                  • This doesn't work under MacOS X.

                                    – Roman Trofimov
                                    Sep 15 '16 at 10:53






                                  • 5





                                    @RomanTrofimov LXC/Docker doesn't either. What a funny comment.

                                    – abourget
                                    Mar 3 '17 at 17:41






                                  • 1





                                    It does not work in centos 7 as well. When I run in my host machine it says docker. Looks like systemd is running as process id 1

                                    – Venkateswara Rao
                                    Jan 26 '18 at 5:02











                                  • @VenkateswaraRao - This must be run inside the container. The intent is to find out if you are inside a docker container or not.

                                    – Govind Kailas
                                    Jan 30 '18 at 4:43






                                  • 1





                                    @SamThomas: launchd, upstart, Solaris SMF, systemd, Sys V style init, BSD style init (these two and some others might call their PID 1 init though), OpenRC, initng, runit. See here. Most modern Linux-based systems would use systemd, some older ones, upstart.... All modern OS X systems would use launchd

                                    – Gert van den Berg
                                    May 23 '18 at 8:16





















                                  • This doesn't work under MacOS X.

                                    – Roman Trofimov
                                    Sep 15 '16 at 10:53






                                  • 5





                                    @RomanTrofimov LXC/Docker doesn't either. What a funny comment.

                                    – abourget
                                    Mar 3 '17 at 17:41






                                  • 1





                                    It does not work in centos 7 as well. When I run in my host machine it says docker. Looks like systemd is running as process id 1

                                    – Venkateswara Rao
                                    Jan 26 '18 at 5:02











                                  • @VenkateswaraRao - This must be run inside the container. The intent is to find out if you are inside a docker container or not.

                                    – Govind Kailas
                                    Jan 30 '18 at 4:43






                                  • 1





                                    @SamThomas: launchd, upstart, Solaris SMF, systemd, Sys V style init, BSD style init (these two and some others might call their PID 1 init though), OpenRC, initng, runit. See here. Most modern Linux-based systems would use systemd, some older ones, upstart.... All modern OS X systems would use launchd

                                    – Gert van den Berg
                                    May 23 '18 at 8:16



















                                  This doesn't work under MacOS X.

                                  – Roman Trofimov
                                  Sep 15 '16 at 10:53





                                  This doesn't work under MacOS X.

                                  – Roman Trofimov
                                  Sep 15 '16 at 10:53




                                  5




                                  5





                                  @RomanTrofimov LXC/Docker doesn't either. What a funny comment.

                                  – abourget
                                  Mar 3 '17 at 17:41





                                  @RomanTrofimov LXC/Docker doesn't either. What a funny comment.

                                  – abourget
                                  Mar 3 '17 at 17:41




                                  1




                                  1





                                  It does not work in centos 7 as well. When I run in my host machine it says docker. Looks like systemd is running as process id 1

                                  – Venkateswara Rao
                                  Jan 26 '18 at 5:02





                                  It does not work in centos 7 as well. When I run in my host machine it says docker. Looks like systemd is running as process id 1

                                  – Venkateswara Rao
                                  Jan 26 '18 at 5:02













                                  @VenkateswaraRao - This must be run inside the container. The intent is to find out if you are inside a docker container or not.

                                  – Govind Kailas
                                  Jan 30 '18 at 4:43





                                  @VenkateswaraRao - This must be run inside the container. The intent is to find out if you are inside a docker container or not.

                                  – Govind Kailas
                                  Jan 30 '18 at 4:43




                                  1




                                  1





                                  @SamThomas: launchd, upstart, Solaris SMF, systemd, Sys V style init, BSD style init (these two and some others might call their PID 1 init though), OpenRC, initng, runit. See here. Most modern Linux-based systems would use systemd, some older ones, upstart.... All modern OS X systems would use launchd

                                  – Gert van den Berg
                                  May 23 '18 at 8:16







                                  @SamThomas: launchd, upstart, Solaris SMF, systemd, Sys V style init, BSD style init (these two and some others might call their PID 1 init though), OpenRC, initng, runit. See here. Most modern Linux-based systems would use systemd, some older ones, upstart.... All modern OS X systems would use launchd

                                  – Gert van den Berg
                                  May 23 '18 at 8:16













                                  1














                                  Building on the accepted answer that tests /proc/*/cgroup ..



                                  awk -F: '$3 ~ /^/$/ {c=1} END{ exit c }' /proc/self/cgroup


                                  So for use in a script or so, a test could be constructed this way.



                                  is_running_in_container() {
                                  awk -F: '$3 ~ /^/$/{ c=1 } END { exit c }' /proc/self/cgroup
                                  }

                                  if is_running_in_container; then
                                  echo "Aye!! I'm in a container"
                                  else
                                  echo "Nay!! I'm not in a container"
                                  fi





                                  share|improve this answer




























                                    1














                                    Building on the accepted answer that tests /proc/*/cgroup ..



                                    awk -F: '$3 ~ /^/$/ {c=1} END{ exit c }' /proc/self/cgroup


                                    So for use in a script or so, a test could be constructed this way.



                                    is_running_in_container() {
                                    awk -F: '$3 ~ /^/$/{ c=1 } END { exit c }' /proc/self/cgroup
                                    }

                                    if is_running_in_container; then
                                    echo "Aye!! I'm in a container"
                                    else
                                    echo "Nay!! I'm not in a container"
                                    fi





                                    share|improve this answer


























                                      1












                                      1








                                      1







                                      Building on the accepted answer that tests /proc/*/cgroup ..



                                      awk -F: '$3 ~ /^/$/ {c=1} END{ exit c }' /proc/self/cgroup


                                      So for use in a script or so, a test could be constructed this way.



                                      is_running_in_container() {
                                      awk -F: '$3 ~ /^/$/{ c=1 } END { exit c }' /proc/self/cgroup
                                      }

                                      if is_running_in_container; then
                                      echo "Aye!! I'm in a container"
                                      else
                                      echo "Nay!! I'm not in a container"
                                      fi





                                      share|improve this answer













                                      Building on the accepted answer that tests /proc/*/cgroup ..



                                      awk -F: '$3 ~ /^/$/ {c=1} END{ exit c }' /proc/self/cgroup


                                      So for use in a script or so, a test could be constructed this way.



                                      is_running_in_container() {
                                      awk -F: '$3 ~ /^/$/{ c=1 } END { exit c }' /proc/self/cgroup
                                      }

                                      if is_running_in_container; then
                                      echo "Aye!! I'm in a container"
                                      else
                                      echo "Nay!! I'm not in a container"
                                      fi






                                      share|improve this answer












                                      share|improve this answer



                                      share|improve this answer










                                      answered Jul 15 '18 at 21:13









                                      shalombshalomb

                                      1,79921614




                                      1,79921614























                                          0














                                          This SO Q&A: "Find out if the OS is running in a virtual environment"; though not the same as the OP's question, it does indeed answer common cases of finding which container you're in (if at all).



                                          In particular, install and read the code of this bash script which seems to work pretty well:



                                          virt-what :



                                          sudo apt install virt-what





                                          share|improve this answer


























                                          • Doesn't work with virt-what version 1.14-1 on Ubuntu 16.04. Needs patch.

                                            – Lucas
                                            Jan 4 '18 at 22:23
















                                          0














                                          This SO Q&A: "Find out if the OS is running in a virtual environment"; though not the same as the OP's question, it does indeed answer common cases of finding which container you're in (if at all).



                                          In particular, install and read the code of this bash script which seems to work pretty well:



                                          virt-what :



                                          sudo apt install virt-what





                                          share|improve this answer


























                                          • Doesn't work with virt-what version 1.14-1 on Ubuntu 16.04. Needs patch.

                                            – Lucas
                                            Jan 4 '18 at 22:23














                                          0












                                          0








                                          0







                                          This SO Q&A: "Find out if the OS is running in a virtual environment"; though not the same as the OP's question, it does indeed answer common cases of finding which container you're in (if at all).



                                          In particular, install and read the code of this bash script which seems to work pretty well:



                                          virt-what :



                                          sudo apt install virt-what





                                          share|improve this answer















                                          This SO Q&A: "Find out if the OS is running in a virtual environment"; though not the same as the OP's question, it does indeed answer common cases of finding which container you're in (if at all).



                                          In particular, install and read the code of this bash script which seems to work pretty well:



                                          virt-what :



                                          sudo apt install virt-what






                                          share|improve this answer














                                          share|improve this answer



                                          share|improve this answer








                                          edited Apr 13 '17 at 12:36









                                          Community

                                          11




                                          11










                                          answered Apr 1 '17 at 3:08









                                          kaiwankaiwan

                                          1,5741220




                                          1,5741220













                                          • Doesn't work with virt-what version 1.14-1 on Ubuntu 16.04. Needs patch.

                                            – Lucas
                                            Jan 4 '18 at 22:23



















                                          • Doesn't work with virt-what version 1.14-1 on Ubuntu 16.04. Needs patch.

                                            – Lucas
                                            Jan 4 '18 at 22:23

















                                          Doesn't work with virt-what version 1.14-1 on Ubuntu 16.04. Needs patch.

                                          – Lucas
                                          Jan 4 '18 at 22:23





                                          Doesn't work with virt-what version 1.14-1 on Ubuntu 16.04. Needs patch.

                                          – Lucas
                                          Jan 4 '18 at 22:23











                                          -3














                                          Maybe this do the trick:



                                          if [ -z $(docker ps -q) ]; then
                                          echo "There is not process currently running"
                                          else
                                          echo "There are processes running"
                                          fi


                                          Is that what you want? Help it help =)






                                          share|improve this answer



















                                          • 1





                                            No docker binary is available from inside of container, obviously.

                                            – toriningen
                                            Jul 5 '18 at 17:02






                                          • 3





                                            Umm, this would fail in situations (e.g. gitlab docker-in-docker) where the controlling container has docker and access to the hosts' docker socket.

                                            – shalomb
                                            Jul 15 '18 at 21:02
















                                          -3














                                          Maybe this do the trick:



                                          if [ -z $(docker ps -q) ]; then
                                          echo "There is not process currently running"
                                          else
                                          echo "There are processes running"
                                          fi


                                          Is that what you want? Help it help =)






                                          share|improve this answer



















                                          • 1





                                            No docker binary is available from inside of container, obviously.

                                            – toriningen
                                            Jul 5 '18 at 17:02






                                          • 3





                                            Umm, this would fail in situations (e.g. gitlab docker-in-docker) where the controlling container has docker and access to the hosts' docker socket.

                                            – shalomb
                                            Jul 15 '18 at 21:02














                                          -3












                                          -3








                                          -3







                                          Maybe this do the trick:



                                          if [ -z $(docker ps -q) ]; then
                                          echo "There is not process currently running"
                                          else
                                          echo "There are processes running"
                                          fi


                                          Is that what you want? Help it help =)






                                          share|improve this answer













                                          Maybe this do the trick:



                                          if [ -z $(docker ps -q) ]; then
                                          echo "There is not process currently running"
                                          else
                                          echo "There are processes running"
                                          fi


                                          Is that what you want? Help it help =)







                                          share|improve this answer












                                          share|improve this answer



                                          share|improve this answer










                                          answered Jun 11 '18 at 15:15









                                          Leonardo Da VinciLeonardo Da Vinci

                                          4016




                                          4016








                                          • 1





                                            No docker binary is available from inside of container, obviously.

                                            – toriningen
                                            Jul 5 '18 at 17:02






                                          • 3





                                            Umm, this would fail in situations (e.g. gitlab docker-in-docker) where the controlling container has docker and access to the hosts' docker socket.

                                            – shalomb
                                            Jul 15 '18 at 21:02














                                          • 1





                                            No docker binary is available from inside of container, obviously.

                                            – toriningen
                                            Jul 5 '18 at 17:02






                                          • 3





                                            Umm, this would fail in situations (e.g. gitlab docker-in-docker) where the controlling container has docker and access to the hosts' docker socket.

                                            – shalomb
                                            Jul 15 '18 at 21:02








                                          1




                                          1





                                          No docker binary is available from inside of container, obviously.

                                          – toriningen
                                          Jul 5 '18 at 17:02





                                          No docker binary is available from inside of container, obviously.

                                          – toriningen
                                          Jul 5 '18 at 17:02




                                          3




                                          3





                                          Umm, this would fail in situations (e.g. gitlab docker-in-docker) where the controlling container has docker and access to the hosts' docker socket.

                                          – shalomb
                                          Jul 15 '18 at 21:02





                                          Umm, this would fail in situations (e.g. gitlab docker-in-docker) where the controlling container has docker and access to the hosts' docker socket.

                                          – shalomb
                                          Jul 15 '18 at 21:02


















                                          draft saved

                                          draft discarded




















































                                          Thanks for contributing an answer to Stack Overflow!


                                          • Please be sure to answer the question. Provide details and share your research!

                                          But avoid



                                          • Asking for help, clarification, or responding to other answers.

                                          • Making statements based on opinion; back them up with references or personal experience.


                                          To learn more, see our tips on writing great answers.




                                          draft saved


                                          draft discarded














                                          StackExchange.ready(
                                          function () {
                                          StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f20010199%2fhow-to-determine-if-a-process-runs-inside-lxc-docker%23new-answer', 'question_page');
                                          }
                                          );

                                          Post as a guest















                                          Required, but never shown





















































                                          Required, but never shown














                                          Required, but never shown












                                          Required, but never shown







                                          Required, but never shown

































                                          Required, but never shown














                                          Required, but never shown












                                          Required, but never shown







                                          Required, but never shown







                                          Popular posts from this blog

                                          Lallio

                                          Unable to find Lightning Node

                                          Futebolista