| 12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849505152535455565758596061626364656667686970717273747576777879808182838485868788 | 
							- #!/bin/bash
 
- set -e
 
- # DinD: a wrapper script which allows docker to be run inside a docker container.
 
- # Original version by Jerome Petazzoni <[email protected]>
 
- # See the blog post: http://blog.docker.com/2013/09/docker-can-now-run-within-docker/
 
- #
 
- # This script should be executed inside a docker container in privilieged mode
 
- # ('docker run --privileged', introduced in docker 0.6).
 
- # Usage: dind CMD [ARG...]
 
- # apparmor sucks and Docker needs to know that it's in a container (c) @tianon
 
- export container=docker
 
- # First, make sure that cgroups are mounted correctly.
 
- CGROUP=/cgroup
 
- mkdir -p "$CGROUP"
 
- if ! mountpoint -q "$CGROUP"; then
 
- 	mount -n -t tmpfs -o uid=0,gid=0,mode=0755 cgroup $CGROUP || {
 
- 		echo >&2 'Could not make a tmpfs mount. Did you use --privileged?'
 
- 		exit 1
 
- 	}
 
- fi
 
- if [ -d /sys/kernel/security ] && ! mountpoint -q /sys/kernel/security; then
 
- 	mount -t securityfs none /sys/kernel/security || {
 
- 		echo >&2 'Could not mount /sys/kernel/security.'
 
- 		echo >&2 'AppArmor detection and -privileged mode might break.'
 
- 	}
 
- fi
 
- # Mount the cgroup hierarchies exactly as they are in the parent system.
 
- for SUBSYS in $(cut -d: -f2 /proc/1/cgroup); do
 
- 	mkdir -p "$CGROUP/$SUBSYS"
 
- 	if ! mountpoint -q $CGROUP/$SUBSYS; then
 
- 		mount -n -t cgroup -o "$SUBSYS" cgroup "$CGROUP/$SUBSYS"
 
- 	fi
 
- 	# The two following sections address a bug which manifests itself
 
- 	# by a cryptic "lxc-start: no ns_cgroup option specified" when
 
- 	# trying to start containers withina container.
 
- 	# The bug seems to appear when the cgroup hierarchies are not
 
- 	# mounted on the exact same directories in the host, and in the
 
- 	# container.
 
- 	# Named, control-less cgroups are mounted with "-o name=foo"
 
- 	# (and appear as such under /proc/<pid>/cgroup) but are usually
 
- 	# mounted on a directory named "foo" (without the "name=" prefix).
 
- 	# Systemd and OpenRC (and possibly others) both create such a
 
- 	# cgroup. To avoid the aforementioned bug, we symlink "foo" to
 
- 	# "name=foo". This shouldn't have any adverse effect.
 
- 	name="${SUBSYS#name=}"
 
- 	if [ "$name" != "$SUBSYS" ]; then
 
- 		ln -s "$SUBSYS" "$CGROUP/$name"
 
- 	fi
 
- 	# Likewise, on at least one system, it has been reported that
 
- 	# systemd would mount the CPU and CPU accounting controllers
 
- 	# (respectively "cpu" and "cpuacct") with "-o cpuacct,cpu"
 
- 	# but on a directory called "cpu,cpuacct" (note the inversion
 
- 	# in the order of the groups). This tries to work around it.
 
- 	if [ "$SUBSYS" = 'cpuacct,cpu' ]; then
 
- 		ln -s "$SUBSYS" "$CGROUP/cpu,cpuacct"
 
- 	fi
 
- done
 
- # Note: as I write those lines, the LXC userland tools cannot setup
 
- # a "sub-container" properly if the "devices" cgroup is not in its
 
- # own hierarchy. Let's detect this and issue a warning.
 
- if ! grep -q :devices: /proc/1/cgroup; then
 
- 	echo >&2 'WARNING: the "devices" cgroup should be in its own hierarchy.'
 
- fi
 
- if ! grep -qw devices /proc/1/cgroup; then
 
- 	echo >&2 'WARNING: it looks like the "devices" cgroup is not mounted.'
 
- fi
 
- # Mount /tmp
 
- mount -t tmpfs none /tmp
 
- if [ $# -gt 0 ]; then
 
- 	exec "$@"
 
- fi
 
- echo >&2 'ERROR: No command specified.'
 
- echo >&2 'You probably want to run hack/make.sh, or maybe a shell?'
 
 
  |