set LimitCORE=infinity to ensure complete core creation,
allows extraction of as much information as possible.
Thanks to Ulrich Obergfell <uobergfe@redhat.com>
and Jeremy Eder <jeder@redhat.com>
Signed-off-by: Lokesh Mandvekar <lsm5@fedoraproject.org>
This systemd.exec setting will construct a new mount namespace for the
docker daemon, and use slave shared-subtree mounts so that volume mounts
propogate correctly into containers.
By having an unshared mount namespace for the daemon it ensures that
mount references are not held by other pids outside of the docker
daemon. Frequently this can be seen in EBUSY or "device or resource
busy" errors.
Signed-off-by: Vincent Batts <vbatts@redhat.com>
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>
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)
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)
Do as was done to f09a78cd21 in the
socket-activation example.
Docker-DCO-1.1-Signed-off-by: Brandon Philips <brandon.philips@coreos.com> (github: philips)
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.
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)
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!.
```
Arnaud Porterie