1+ #! /bin/bash
2+ set -e
3+
4+ # DinD: a wrapper script which allows docker to be run inside a docker container.
5+ # Original version by Jerome Petazzoni <jerome@dotcloud.com>
6+ # See the blog post: http://blog.docker.io/2013/09/docker-can-now-run-within-docker/
7+ #
8+ # This script should be executed inside a docker container in privilieged mode
9+ # ('docker run --privileged', introduced in docker 0.6).
10+
11+ # Usage: dind CMD [ARG...]
12+
13+ # apparmor sucks and Docker needs to know that it's in a container (c) @tianon
14+ export container=docker
15+
16+ # First, make sure that cgroups are mounted correctly.
17+ CGROUP=/cgroup
18+
19+ mkdir -p " $CGROUP "
20+
21+ if ! mountpoint -q " $CGROUP " ; then
22+ mount -n -t tmpfs -o uid=0,gid=0,mode=0755 cgroup $CGROUP || {
23+ echo >&2 ' Could not make a tmpfs mount. Did you use --privileged?'
24+ exit 1
25+ }
26+ fi
27+
28+ if [ -d /sys/kernel/security ] && ! mountpoint -q /sys/kernel/security; then
29+ mount -t securityfs none /sys/kernel/security || {
30+ echo >&2 ' Could not mount /sys/kernel/security.'
31+ echo >&2 ' AppArmor detection and -privileged mode might break.'
32+ }
33+ fi
34+
35+ # Mount the cgroup hierarchies exactly as they are in the parent system.
36+ for SUBSYS in $( cut -d: -f2 /proc/1/cgroup) ; do
37+ mkdir -p " $CGROUP /$SUBSYS "
38+ if ! mountpoint -q $CGROUP /$SUBSYS ; then
39+ mount -n -t cgroup -o " $SUBSYS " cgroup " $CGROUP /$SUBSYS "
40+ fi
41+
42+ # The two following sections address a bug which manifests itself
43+ # by a cryptic "lxc-start: no ns_cgroup option specified" when
44+ # trying to start containers withina container.
45+ # The bug seems to appear when the cgroup hierarchies are not
46+ # mounted on the exact same directories in the host, and in the
47+ # container.
48+
49+ # Named, control-less cgroups are mounted with "-o name=foo"
50+ # (and appear as such under /proc/<pid>/cgroup) but are usually
51+ # mounted on a directory named "foo" (without the "name=" prefix).
52+ # Systemd and OpenRC (and possibly others) both create such a
53+ # cgroup. To avoid the aforementioned bug, we symlink "foo" to
54+ # "name=foo". This shouldn't have any adverse effect.
55+ name=" ${SUBSYS# name=} "
56+ if [ " $name " != " $SUBSYS " ]; then
57+ ln -s " $SUBSYS " " $CGROUP /$name "
58+ fi
59+
60+ # Likewise, on at least one system, it has been reported that
61+ # systemd would mount the CPU and CPU accounting controllers
62+ # (respectively "cpu" and "cpuacct") with "-o cpuacct,cpu"
63+ # but on a directory called "cpu,cpuacct" (note the inversion
64+ # in the order of the groups). This tries to work around it.
65+ if [ " $SUBSYS " = ' cpuacct,cpu' ]; then
66+ ln -s " $SUBSYS " " $CGROUP /cpu,cpuacct"
67+ fi
68+ done
69+
70+ # Note: as I write those lines, the LXC userland tools cannot setup
71+ # a "sub-container" properly if the "devices" cgroup is not in its
72+ # own hierarchy. Let's detect this and issue a warning.
73+ if ! grep -q :devices: /proc/1/cgroup; then
74+ echo >&2 ' WARNING: the "devices" cgroup should be in its own hierarchy.'
75+ fi
76+ if ! grep -qw devices /proc/1/cgroup; then
77+ echo >&2 ' WARNING: it looks like the "devices" cgroup is not mounted.'
78+ fi
79+
80+ # Mount /tmp
81+ # mount -t tmpfs none /tmp
82+
83+ if [ $# -gt 0 ]; then
84+ exec " $@ "
85+ fi
86+
87+ echo >&2 ' ERROR: No command specified.'
88+ echo >&2 ' You probably want to run hack/make.sh, or maybe a shell?'
0 commit comments