moby--moby/contrib/init/systemd/docker.socket

[Unit]
Description=Docker Socket for the API
PartOf=docker.service

[Socket]
ListenStream=/var/run/docker.sock
SocketMode=0660
SocketUser=root
SocketGroup=docker

[Install]
WantedBy=sockets.target
server: add socket activation 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) 2013-12-07 00:19:30 -05:00			`[Unit]`
			`Description=Docker Socket for the API`
Fix system socket/service unit files 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> 2014-10-07 14:09:08 -04:00			`PartOf=docker.service`
server: add socket activation 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) 2013-12-07 00:19:30 -05:00
			`[Socket]`
			`ListenStream=/var/run/docker.sock`
Fix the systemd socket activation socket permissions Fixes #6836 Docker-DCO-1.1-Signed-off-by: Andrew Page <admwiggin@gmail.com> (github: tianon) 2014-07-07 10:09:25 -04:00			`SocketMode=0660`
			`SocketUser=root`
			`SocketGroup=docker`
server: add socket activation 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) 2013-12-07 00:19:30 -05:00
			`[Install]`
			`WantedBy=sockets.target`