moby--moby/contrib/init/upstart/docker.conf

61 lines
1.5 KiB
Plaintext
Raw Normal View History

description "Docker daemon"
start on (filesystem and net-device-up IFACE!=lo)
stop on runlevel [!2345]
limit nofile 524288 1048576
limit nproc 524288 1048576
respawn
kill timeout 20
pre-start script
# see also https://github.com/tianon/cgroupfs-mount/blob/master/cgroupfs-mount
if grep -v '^#' /etc/fstab | grep -q cgroup \
|| [ ! -e /proc/cgroups ] \
|| [ ! -d /sys/fs/cgroup ]; then
exit 0
fi
if ! mountpoint -q /sys/fs/cgroup; then
mount -t tmpfs -o uid=0,gid=0,mode=0755 cgroup /sys/fs/cgroup
fi
(
cd /sys/fs/cgroup
for sys in $(awk '!/^#/ { if ($4 == 1) print $1 }' /proc/cgroups); do
mkdir -p $sys
if ! mountpoint -q $sys; then
if ! mount -n -t cgroup -o $sys cgroup $sys; then
rmdir $sys || true
fi
fi
done
)
end script
script
# modify these in /etc/default/$UPSTART_JOB (/etc/default/docker)
DOCKER=/usr/bin/$UPSTART_JOB
DOCKER_OPTS=
if [ -f /etc/default/$UPSTART_JOB ]; then
. /etc/default/$UPSTART_JOB
fi
exec "$DOCKER" daemon $DOCKER_OPTS
end script
upstart: Don't emit "started" event until docker.sock is available Fixes #6647: Other upstart jobs that depend on docker by specifying "start on started docker" would often start before the docker daemon was ready, so they'd fail with "Cannot connect to the Docker daemon" or "dial unix /var/run/docker.sock: no such file or directory". This is because "docker -d" doesn't daemonize, it runs in the foreground, so upstart can't know when the daemon is ready to receive incoming connections. (Traditionally, a daemon will create all necessary sockets and then fork to signal that it's ready; according to @tianon this "isn't possible in Go"[1]. See also [2].) Presumably this isn't a problem with systemd init with its socket activation. The SysV init scripts may or may not suffer from this problem but I have no motivation to fix them. This commit adds a "post-start" stanza to the upstart configuration that waits for the socket to be available. Upstart won't emit the "started" event until the "post-start" script completes.[3] Note that the system administrator might have specified a different path for the socket, or a tcp socket instead, by customising /etc/default/docker. In that case we don't try to figure out what the new socket is, but at least we don't wait in vain for /var/run/docker.sock to appear. If the main script (`docker -d`) fails to start, the `initctl status $UPSTART_JOB | grep -q "stop/"` line ensures that we don't loop forever. I stole this idea from Steve Langasek.[4] If for some reason we *still* end up in an infinite loop --I guess `docker -d` must have hung-- then at least we'll be able to see the "Waiting for /var/run/docker.sock" debug output in /var/log/upstart/docker.log. I considered using inotifywait instead of sleep, but it isn't worth the complexity & the extra dependency. [1] https://github.com/docker/docker/issues/6647#issuecomment-47001613 [2] https://code.google.com/p/go/issues/detail?id=227 [3] http://upstart.ubuntu.com/cookbook/#post-start [4] https://lists.ubuntu.com/archives/upstart-devel/2013-April/002492.html Signed-off-by: David Röthlisberger <david@rothlis.net>
2014-11-22 08:25:57 +00:00
# Don't emit "started" event until docker.sock is ready.
# See https://github.com/docker/docker/issues/6647
post-start script
DOCKER_OPTS=
if [ -f /etc/default/$UPSTART_JOB ]; then
. /etc/default/$UPSTART_JOB
fi
if ! printf "%s" "$DOCKER_OPTS" | grep -qE -e '-H|--host'; then
while ! [ -e /var/run/docker.sock ]; do
initctl status $UPSTART_JOB | grep -qE "(stop|respawn)/" && exit 1
upstart: Don't emit "started" event until docker.sock is available Fixes #6647: Other upstart jobs that depend on docker by specifying "start on started docker" would often start before the docker daemon was ready, so they'd fail with "Cannot connect to the Docker daemon" or "dial unix /var/run/docker.sock: no such file or directory". This is because "docker -d" doesn't daemonize, it runs in the foreground, so upstart can't know when the daemon is ready to receive incoming connections. (Traditionally, a daemon will create all necessary sockets and then fork to signal that it's ready; according to @tianon this "isn't possible in Go"[1]. See also [2].) Presumably this isn't a problem with systemd init with its socket activation. The SysV init scripts may or may not suffer from this problem but I have no motivation to fix them. This commit adds a "post-start" stanza to the upstart configuration that waits for the socket to be available. Upstart won't emit the "started" event until the "post-start" script completes.[3] Note that the system administrator might have specified a different path for the socket, or a tcp socket instead, by customising /etc/default/docker. In that case we don't try to figure out what the new socket is, but at least we don't wait in vain for /var/run/docker.sock to appear. If the main script (`docker -d`) fails to start, the `initctl status $UPSTART_JOB | grep -q "stop/"` line ensures that we don't loop forever. I stole this idea from Steve Langasek.[4] If for some reason we *still* end up in an infinite loop --I guess `docker -d` must have hung-- then at least we'll be able to see the "Waiting for /var/run/docker.sock" debug output in /var/log/upstart/docker.log. I considered using inotifywait instead of sleep, but it isn't worth the complexity & the extra dependency. [1] https://github.com/docker/docker/issues/6647#issuecomment-47001613 [2] https://code.google.com/p/go/issues/detail?id=227 [3] http://upstart.ubuntu.com/cookbook/#post-start [4] https://lists.ubuntu.com/archives/upstart-devel/2013-April/002492.html Signed-off-by: David Röthlisberger <david@rothlis.net>
2014-11-22 08:25:57 +00:00
echo "Waiting for /var/run/docker.sock"
sleep 0.1
done
echo "/var/run/docker.sock is up"
fi
end script