How to determine if a process runs inside lxc/Docker?
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
add a comment |
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
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
add a comment |
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
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
linux bash docker
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
add a comment |
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
add a comment |
13 Answers
13
active
oldest
votes
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.
12
docker now usesdockerinstead oflxcin 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_eventand7: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/cgroupworks for me on Docker 18.09.
– ferkulat
Feb 1 at 11:04
add a comment |
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.
11
Important note: the.dockerinitfile has been removed in recent versions of Docker, so this method won't work any more. As of this writing, the.dockerenvfile is still kept around, so perhaps that could be used instead.
– Jason R
Apr 27 '16 at 1:10
On Debian/bin/running-in-containeris provided byupstart. 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.dockerenvis 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
add a comment |
On a new ubuntu 16.04 system, new systemd & lxc 2.0
sudo grep -qa container=lxc /proc/1/environ
add a comment |
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
add a comment |
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()
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
add a comment |
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.
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
add a comment |
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.
This one works not only for docker (I didn't check that), but more importantly for lxd/lxc containers (checked), where/proc/1/cgroupdoes 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 envdoes not give anything that looks like that variable
– Archimedes Trajano
Mar 10 at 16:01
add a comment |
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.
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
add a comment |
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)
add a comment |
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
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 1initthough), OpenRC, initng, runit. See here. Most modern Linux-based systems would usesystemd, some older ones, upstart.... All modern OS X systems would uselaunchd
– Gert van den Berg
May 23 '18 at 8:16
|
show 2 more comments
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
add a comment |
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
Doesn't work withvirt-whatversion 1.14-1 on Ubuntu 16.04. Needs patch.
– Lucas
Jan 4 '18 at 22:23
add a comment |
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 =)
1
Nodockerbinary 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 hasdockerand access to the hosts' docker socket.
– shalomb
Jul 15 '18 at 21:02
add a comment |
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
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
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.
12
docker now usesdockerinstead oflxcin 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_eventand7: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/cgroupworks for me on Docker 18.09.
– ferkulat
Feb 1 at 11:04
add a comment |
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.
12
docker now usesdockerinstead oflxcin 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_eventand7: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/cgroupworks for me on Docker 18.09.
– ferkulat
Feb 1 at 11:04
add a comment |
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.
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.
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 usesdockerinstead oflxcin 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_eventand7: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/cgroupworks for me on Docker 18.09.
– ferkulat
Feb 1 at 11:04
add a comment |
12
docker now usesdockerinstead oflxcin 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_eventand7: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/cgroupworks 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
add a comment |
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.
11
Important note: the.dockerinitfile has been removed in recent versions of Docker, so this method won't work any more. As of this writing, the.dockerenvfile is still kept around, so perhaps that could be used instead.
– Jason R
Apr 27 '16 at 1:10
On Debian/bin/running-in-containeris provided byupstart. 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.dockerenvis 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
add a comment |
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.
11
Important note: the.dockerinitfile has been removed in recent versions of Docker, so this method won't work any more. As of this writing, the.dockerenvfile is still kept around, so perhaps that could be used instead.
– Jason R
Apr 27 '16 at 1:10
On Debian/bin/running-in-containeris provided byupstart. 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.dockerenvis 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
add a comment |
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.
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.
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.dockerinitfile has been removed in recent versions of Docker, so this method won't work any more. As of this writing, the.dockerenvfile is still kept around, so perhaps that could be used instead.
– Jason R
Apr 27 '16 at 1:10
On Debian/bin/running-in-containeris provided byupstart. 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.dockerenvis 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
add a comment |
11
Important note: the.dockerinitfile has been removed in recent versions of Docker, so this method won't work any more. As of this writing, the.dockerenvfile is still kept around, so perhaps that could be used instead.
– Jason R
Apr 27 '16 at 1:10
On Debian/bin/running-in-containeris provided byupstart. 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.dockerenvis 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
add a comment |
On a new ubuntu 16.04 system, new systemd & lxc 2.0
sudo grep -qa container=lxc /proc/1/environ
add a comment |
On a new ubuntu 16.04 system, new systemd & lxc 2.0
sudo grep -qa container=lxc /proc/1/environ
add a comment |
On a new ubuntu 16.04 system, new systemd & lxc 2.0
sudo grep -qa container=lxc /proc/1/environ
On a new ubuntu 16.04 system, new systemd & lxc 2.0
sudo grep -qa container=lxc /proc/1/environ
answered Mar 2 '16 at 15:12
larsslarss
15112
15112
add a comment |
add a comment |
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
add a comment |
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
add a comment |
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
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
answered Jan 10 '17 at 1:40
oNaiPsoNaiPs
183110
183110
add a comment |
add a comment |
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()
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
add a comment |
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()
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
add a comment |
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()
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()
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
add a comment |
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
add a comment |
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.
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
add a comment |
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.
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
add a comment |
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.
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.
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
add a comment |
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
add a comment |
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.
This one works not only for docker (I didn't check that), but more importantly for lxd/lxc containers (checked), where/proc/1/cgroupdoes 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 envdoes not give anything that looks like that variable
– Archimedes Trajano
Mar 10 at 16:01
add a comment |
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.
This one works not only for docker (I didn't check that), but more importantly for lxd/lxc containers (checked), where/proc/1/cgroupdoes 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 envdoes not give anything that looks like that variable
– Archimedes Trajano
Mar 10 at 16:01
add a comment |
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.
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.
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/cgroupdoes 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 envdoes not give anything that looks like that variable
– Archimedes Trajano
Mar 10 at 16:01
add a comment |
This one works not only for docker (I didn't check that), but more importantly for lxd/lxc containers (checked), where/proc/1/cgroupdoes 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 envdoes 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
add a comment |
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.
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
add a comment |
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.
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
add a comment |
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.
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.
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
add a comment |
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
add a comment |
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)
add a comment |
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)
add a comment |
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)
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)
answered Sep 26 '17 at 22:54
blakevblakev
2,23311641
2,23311641
add a comment |
add a comment |
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
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 1initthough), OpenRC, initng, runit. See here. Most modern Linux-based systems would usesystemd, some older ones, upstart.... All modern OS X systems would uselaunchd
– Gert van den Berg
May 23 '18 at 8:16
|
show 2 more comments
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
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 1initthough), OpenRC, initng, runit. See here. Most modern Linux-based systems would usesystemd, some older ones, upstart.... All modern OS X systems would uselaunchd
– Gert van den Berg
May 23 '18 at 8:16
|
show 2 more comments
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
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
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 1initthough), OpenRC, initng, runit. See here. Most modern Linux-based systems would usesystemd, some older ones, upstart.... All modern OS X systems would uselaunchd
– Gert van den Berg
May 23 '18 at 8:16
|
show 2 more comments
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 1initthough), OpenRC, initng, runit. See here. Most modern Linux-based systems would usesystemd, some older ones, upstart.... All modern OS X systems would uselaunchd
– 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
|
show 2 more comments
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
add a comment |
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
add a comment |
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
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
answered Jul 15 '18 at 21:13
shalombshalomb
1,79921614
1,79921614
add a comment |
add a comment |
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
Doesn't work withvirt-whatversion 1.14-1 on Ubuntu 16.04. Needs patch.
– Lucas
Jan 4 '18 at 22:23
add a comment |
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
Doesn't work withvirt-whatversion 1.14-1 on Ubuntu 16.04. Needs patch.
– Lucas
Jan 4 '18 at 22:23
add a comment |
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
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
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 withvirt-whatversion 1.14-1 on Ubuntu 16.04. Needs patch.
– Lucas
Jan 4 '18 at 22:23
add a comment |
Doesn't work withvirt-whatversion 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
add a comment |
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 =)
1
Nodockerbinary 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 hasdockerand access to the hosts' docker socket.
– shalomb
Jul 15 '18 at 21:02
add a comment |
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 =)
1
Nodockerbinary 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 hasdockerand access to the hosts' docker socket.
– shalomb
Jul 15 '18 at 21:02
add a comment |
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 =)
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 =)
answered Jun 11 '18 at 15:15
Leonardo Da VinciLeonardo Da Vinci
4016
4016
1
Nodockerbinary 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 hasdockerand access to the hosts' docker socket.
– shalomb
Jul 15 '18 at 21:02
add a comment |
1
Nodockerbinary 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 hasdockerand 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
add a comment |
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.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
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

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