2014-12-19 02:20:59 -05:00
|
|
|
#!/bin/bash
|
|
|
|
|
|
|
|
# see test-integration-cli for example usage of this script
|
|
|
|
|
2015-05-29 16:07:16 -04:00
|
|
|
export PATH="$ABS_DEST/../binary:$ABS_DEST/../dynbinary:$ABS_DEST/../gccgo:$ABS_DEST/../dyngccgo:$PATH"
|
2014-12-19 02:20:59 -05:00
|
|
|
|
|
|
|
if ! command -v docker &> /dev/null; then
|
|
|
|
echo >&2 'error: binary or dynbinary must be run before .integration-daemon-start'
|
|
|
|
false
|
|
|
|
fi
|
|
|
|
|
|
|
|
# intentionally open a couple bogus file descriptors to help test that they get scrubbed in containers
|
|
|
|
exec 41>&1 42>&2
|
|
|
|
|
2015-01-27 19:40:11 -05:00
|
|
|
export DOCKER_GRAPHDRIVER=${DOCKER_GRAPHDRIVER:-vfs}
|
|
|
|
export DOCKER_EXECDRIVER=${DOCKER_EXECDRIVER:-native}
|
2015-04-07 19:53:39 -04:00
|
|
|
export DOCKER_USERLANDPROXY=${DOCKER_USERLANDPROXY:-true}
|
2014-12-19 02:20:59 -05:00
|
|
|
|
2015-04-15 02:39:15 -04:00
|
|
|
# example usage: DOCKER_STORAGE_OPTS="dm.basesize=20G,dm.loopdatasize=200G"
|
|
|
|
storage_params=""
|
|
|
|
if [ -n "$DOCKER_STORAGE_OPTS" ]; then
|
|
|
|
IFS=','
|
|
|
|
for i in ${DOCKER_STORAGE_OPTS}; do
|
|
|
|
storage_params="--storage-opt $i $storage_params"
|
|
|
|
done
|
|
|
|
unset IFS
|
|
|
|
fi
|
|
|
|
|
2014-11-20 00:19:16 -05:00
|
|
|
if [ -z "$DOCKER_TEST_HOST" ]; then
|
2015-05-04 16:20:01 -04:00
|
|
|
# Start apparmor if it is enabled
|
|
|
|
if [ "$(cat /sys/module/apparmor/parameters/enabled)" == "Y" ]; then
|
|
|
|
# reset container variable so apparmor profile is applied to process
|
|
|
|
# see https://github.com/docker/libcontainer/blob/master/apparmor/apparmor.go#L16
|
|
|
|
export container=""
|
|
|
|
(
|
|
|
|
set -x
|
|
|
|
/etc/init.d/apparmor start
|
|
|
|
)
|
|
|
|
fi
|
|
|
|
|
2015-02-14 05:27:31 -05:00
|
|
|
export DOCKER_HOST="unix://$(cd "$DEST" && pwd)/docker.sock" # "pwd" tricks to make sure $DEST is an absolute path, not a relative one
|
2014-12-24 00:57:14 -05:00
|
|
|
( set -x; exec \
|
|
|
|
docker --daemon --debug \
|
2015-02-14 05:27:31 -05:00
|
|
|
--host "$DOCKER_HOST" \
|
2014-12-24 00:57:14 -05:00
|
|
|
--storage-driver "$DOCKER_GRAPHDRIVER" \
|
|
|
|
--exec-driver "$DOCKER_EXECDRIVER" \
|
|
|
|
--pidfile "$DEST/docker.pid" \
|
2015-04-07 19:53:39 -04:00
|
|
|
--userland-proxy="$DOCKER_USERLANDPROXY" \
|
2015-04-15 02:39:15 -04:00
|
|
|
$storage_params \
|
2014-12-24 00:57:14 -05:00
|
|
|
&> "$DEST/docker.log"
|
|
|
|
) &
|
Fix daemon start/stop logic in hack/make/* scripts
From the Bash manual's `set -e` description:
(https://www.gnu.org/software/bash/manual/bashref.html#index-set)
> Exit immediately if a pipeline (see Pipelines), which may consist of a
> single simple command (see Simple Commands), a list (see Lists), or a
> compound command (see Compound Commands) returns a non-zero status.
> The shell does not exit if the command that fails is part of the
> command list immediately following a while or until keyword, part of
> the test in an if statement, part of any command executed in a && or
> || list except the command following the final && or ||, any command
> in a pipeline but the last, or if the command’s return status is being
> inverted with !. If a compound command other than a subshell returns a
> non-zero status because a command failed while -e was being ignored,
> the shell does not exit.
Additionally, further down:
> If a compound command or shell function executes in a context where -e
> is being ignored, none of the commands executed within the compound
> command or function body will be affected by the -e setting, even if
> -e is set and a command returns a failure status. If a compound
> command or shell function sets -e while executing in a context where
> -e is ignored, that setting will not have any effect until the
> compound command or the command containing the function call
> completes.
Thus, the only way to have our `.integration-daemon-stop` script
actually run appropriately to clean up our daemon on test/script failure
is to use `trap ... EXIT`, which we traditionally avoid because it does
not have any stacking capabilities, but in this case is a reasonable
compromise because it's going to be the only script using it (for now,
at least; we can evaluate more complex solutions in the future if they
actually become necessary).
The alternatives were much less reasonable. One is to have the entire
complex chains in any script wanting to use `.integration-daemon-start`
/ `.integration-daemon-stop` be chained together with `&&` in an `if`
block, which is untenable. The other I could think of was taking the
body of these scripts out into separate scripts, essentially meaning
we'd need two files for each of these, which further complicates the
maintenance.
Add to that the fact that our `trap ... EXIT` is scoped to the enclosing
subshell (`( ... )`) and we're in even more reasonable territory with
this pattern.
Signed-off-by: Andrew "Tianon" Page <admwiggin@gmail.com>
2015-04-17 18:19:34 -04:00
|
|
|
trap "source '${MAKEDIR}/.integration-daemon-stop'" EXIT # make sure that if the script exits unexpectedly, we stop this daemon we just started
|
2014-11-20 00:19:16 -05:00
|
|
|
else
|
2014-12-24 00:57:14 -05:00
|
|
|
export DOCKER_HOST="$DOCKER_TEST_HOST"
|
2014-11-20 00:19:16 -05:00
|
|
|
fi
|
2015-02-14 05:27:31 -05:00
|
|
|
|
|
|
|
# give it a second to come up so it's "ready"
|
|
|
|
tries=10
|
|
|
|
while ! docker version &> /dev/null; do
|
|
|
|
(( tries-- ))
|
|
|
|
if [ $tries -le 0 ]; then
|
|
|
|
if [ -z "$DOCKER_HOST" ]; then
|
|
|
|
echo >&2 "error: daemon failed to start"
|
|
|
|
echo >&2 " check $DEST/docker.log for details"
|
|
|
|
else
|
|
|
|
echo >&2 "error: daemon at $DOCKER_HOST fails to 'docker version':"
|
|
|
|
docker version >&2 || true
|
|
|
|
fi
|
|
|
|
false
|
|
|
|
fi
|
|
|
|
sleep 2
|
|
|
|
done
|