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>
Upstream-commit: f42c0a53a38a2a141bec8768d0836a3726de4a83
Component: engine
Two problems how they are today:
In the current systemd unit files it is impossible to have the
docker.service started at system boot. Instead enableing docker.service
will actually enable docker.socket. This is a problem, as that means
any container with --restart=always will not launch on reboot. And of
course as soon as you log in and type docker ps, docker.service will be
launched and now your images are running. Talk about a PITA to debug!
The fix is to just install docker.service when people ask docker.service
to be enabled. If an admin wants to enable docker.socket instead, that
is fine and will work just as it does today.
The second problem is a common docker devel workflow, although not
something normal admins would hit. In this case consider a dev doing
the following:
systemctl stop docker.service
docker -d
[run commands]
[^C]
systemctl start docker.service
Running docker -d (without -F fd://) will clean up the
/var/run/docker.sock when it exits. Remember, you just ran the docker
daemon not telling it about socket actviation, so cleaning up its socket
makes sense! The new docker, started by systemd will expect socket
activation, but the last one cleaned up the docker.sock. So things are
just broken. You can, today, work around this by restarting
docker.socket. This fixes it by telling docker.socket that it is
PartOf=docker.service. So when docker.service is
started/stopped/restarted docker.socket will also be
started/stopped/restarted. So the above semi-common devel workflow will
be fine. When docker.service is stopped, so is docker.socket, docker
-d (without -F fd://) will create and delete /var/run/docker.sock.
Starting docker.service again will restart docker.socket, which will
create the file an all is happy in the word.
Signed-off-by: Eric Paris <eparis@redhat.com>
Upstream-commit: 053c3557b3198466ecfbe066fefdbab2a78771d5
Component: engine
This change will allow the Docker daemon's init script to wait up to 5
minutes before being forcibly terminated by the initscript. Many
non-trivial containers will take more than the default 3 seconds to
stop, which can result in containers whose rootfs is still mounted and
will not restart when the daemon starts up again, or worse, orphan
processes that are still running.
Signed-off-by: Steven Merrill <steven.merrill@gmail.com>
Upstream-commit: 640d2ef6f54d96ac4fc3f0f745cb1e6a35148607
Component: engine
- add `set -e` to make failing commands bail the script
- remove trailing `exit 0` which is just extraneous anyhow
- adjust `status_of_proc` options to pass in `$DOCKER_DESC` so we get consistently styled messages like `Docker is running` or `Docker is not running` or `could not access PID file for Docker`
Signed-off-by: Andrew Page <admwiggin@gmail.com>
Upstream-commit: 478fdaf93353c70a26c0043dadb650fd2f101c40
Component: engine
This should not be done by default but used by adminsys with a drop-in.d file,
for buggy daemons which crash without known fixes.
Docker-DCO-1.1-Signed-off-by: Sébastien Luttringer <seblu@seblu.net> (github: seblu)
Upstream-commit: 533916fa6bb0b19fb887b5b0b2b704b224154b41
Component: engine
As requested after #7021 add me as a maintainer alongside the sword
toting @lsm5.
Docker-DCO-1.1-Signed-off-by: Brandon Philips <brandon.philips@coreos.com> (github: philips)
Upstream-commit: 81307680142d5ddd8e80c70c5da8afc799318556
Component: engine
We use the start-stop-daemon pid creation mechanism in addition the intrinsic built into docker. This means the pid file is guaranteed to be written out by the time the script exits.
See #6184.
Docker-DCO-1.1-Signed-off-by: Joe Beda <joe.github@bedafamily.com> (github: jbeda)
Upstream-commit: c11fadb282ea7e96eef2280a5e422fd2c94e8c45
Component: engine
This resolves a problem that I have been having where docker starts before networking is up. See issue #5944 for more details.
Docker-DCO-1.1-Signed-off-by: Jeffrey Bolle <jeffreybolle@gmail.com> (github: jeffreybolle)
Upstream-commit: c52889db27a2af09ed7f6c92f2d6c6fd9737bf63
Component: engine
This changes the upstart init script to start on `local-filesystems`.
Docker-DCO-1.1-Signed-off-by: Cristian Staretu <cristian.staretu@gmail.com> (github: unclejack)
Upstream-commit: ba0c8292917560b45f840f187c2a8f452550705d
Component: engine
Docker-DCO-1.1-Signed-off-by: Chris St. Pierre <chris.a.st.pierre@gmail.com> (github: stpierre)
Upstream-commit: 1ee423bd5dd7abf6f5f4662132b77fdebf14529a
Component: engine
Fixes#5359
Docker-DCO-1.1-Signed-off-by: Chris St. Pierre <chris.a.st.pierre@gmail.com> (github: stpierre)
Upstream-commit: a598dba1346c9f2e878e8250a9d641a2206cb4e5
Component: engine
It's fine to list both here because "Should-Start" is a loose binding (ie, if the listed service exists, it'll be started first, but otherwise, this one will start without it).
Docker-DCO-1.1-Signed-off-by: Andrew Page <admwiggin@gmail.com> (github: tianon)
Upstream-commit: 36d913078b7ea0138dbc5d561703d068e7e31934
Component: engine
These were found using `git grep -nE '[^-a-zA-Z0-9<>]-[a-zA-Z0-9]{2}'` (fair warning: _many_ false positives there).
Docker-DCO-1.1-Signed-off-by: Andrew Page <admwiggin@gmail.com> (github: tianon)
Upstream-commit: 44fe8cbbd174b5d85d4a063ed270f6b9d2279b70
Component: engine
Docker-DCO-1.1-Signed-off-by: Adam Miller <admiller@redhat.com> (github: maxamillion)
Upstream-commit: 4317011e21b4e4025a9c92c7dc255fbf62af573a
Component: engine
Docker-DCO-1.1-Signed-off-by: Adam Miller <admiller@redhat.com> (github: maxamillion)
Upstream-commit: 2222cba5acd3fe663d492d7bc3fd4787d4c9869f
Component: engine
Do as was done to f09a78cd219b24d4308034c8dd13410cfe5fbec7 in the
socket-activation example.
Docker-DCO-1.1-Signed-off-by: Brandon Philips <brandon.philips@coreos.com> (github: philips)
Upstream-commit: 4dab34c2045b7bcc735227867126f0796cbb09c1
Component: engine
Docker-DCO-1.1-Signed-off-by: Lokesh Mandvekar <lsm5@redhat.com> (github: lsm5)
systemd service no longer does '/bin/mount/ --make-rprivate /'.
Core issue fixed by Alex Larsson (commit 157d99a).
ip forwarding enabled.
Upstream-commit: f09a78cd219b24d4308034c8dd13410cfe5fbec7
Component: engine
Docker does this now via 157d99a72786c454dfaad8b0800914cc80879aa8
Docker-DCO-1.1-Signed-off-by: Brandon Philips <brandon.philips@coreos.com> (github: philips)
Upstream-commit: 1f44921c51883e923ed82ed4e30eca6f79702cfb
Component: engine
This adds the ability to socket activate docker by passing in
`-H fd://*` along with examples systemd configuration files.
The fastest way to test this is to run:
```
/usr/lib/systemd/systemd-activate -l 127.0.0.1:2001 /usr/bin/docker -d -H 'fd://*'
docker -H tcp://127.0.0.1:2001 ps
```
Docker-DCO-1.1-Signed-off-by: Brandon Philips <brandon.philips@coreos.com> (github: philips)
Upstream-commit: 87fb2c973d8f9a8a1868ab0c2da504095d04715b
Component: engine
Update sysvinit script to fix a few inconsistencies and be more useful/correct downstream
Upstream-commit: 8ad46ef401fd0665efe16f50021a5a48a14b51e5
Component: engine
Fix-up the docker service file description to declare what the service is not what it does.
When a systemd machine starts up the Description of each unit scrolls by instead of the service's filename. Because the current description doesn't say what it is it isn't very friendly:
```
Oct 31 20:40:49 localhost systemd[1]: Started Update Engine.
Oct 31 20:40:49 localhost systemd[1]: Starting Multi-User System.
Oct 31 20:40:49 localhost systemd[1]: Reached target Multi-User System.
Oct 31 20:40:49 localhost systemd[1]: Starting Easily create lightweight, portable, self-sufficient containers from any application!...
Oct 31 20:40:49 localhost systemd[1]: Started Easily create lightweight, portable, self-sufficient containers from any application!.
```
Upstream-commit: 393562340c6f386a837eac9a616c456dc54faa4f
Component: engine
