Hide Forgot
Version-Release number of selected component (if applicable): docker-io-1.4.1-8.fc21.x86_64 How reproducible: Always Steps to Reproduce: $ docker ps Actual results: FATA[0000] Cannot connect to the Docker daemon. Is 'docker -d' running on this host? Expected results: /var/run/docker.sock should automatically start `docker.service` via socket activation. This was the case on fedora 20. Additional info: I looked in the package history, and it looks like it was disabled by: commit aecb9bfe55824e2c9c7be4afce3ac8dd7e3395f5 Author: Lokesh Mandvekar <lsm5@fedoraproject.org> Date: Fri Jan 16 17:06:40 2015 +0000 docker group and socket activation not used NVR: docker-io-1.4.1-7 - sysconfig file updates Signed-off-by: Lokesh Mandvekar <lsm5@fedoraproject.org> I assume there's a reason for this, but there's no bugzilla or other issue reference, and no description of why the functionality should be removed. The removal of socket activation is pretty annoying, so it would be great if it could be re-enabled. If it can't be enabled, it would be good to document why.
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
Sorry about the late reply, socket-activation was removed mainly because of https://github.com/docker/docker/pull/10144#issuecomment-70315230 . Regarding docker not starting, please make sure your /etc/sysconfig/docker does _not_ have '-H fd://' included in $OPTIONS. Once, that's done restart the daemon and everything should work fine. HTH.
Thanks for the response, it's good to know the reason behind its removal. > Regarding docker not starting, please make sure your /etc/sysconfig/docker does _not_ have '-H fd://' included in $OPTIONS. Once, that's done restart the daemon and everything should work fine. I'm not sure what you're addressing here. Docker starts if I start the service explicitly (or I assume if I enabled it via multi-user.wants.d or something, but I don't want to do that because I use docker very rarely). Is this advice just in case `systemctl start docker.service` fails? (either way, that option is already not in my config; I haven't changed the system defaults).
docker socket activation breaks the ability for docker to start services automatically. Since docker mimics some of the functionality of systemd, users setting a container to start automatically when the machine reboots would not work with docker starting on socket activation, since no process would be connecting to the /run/docker.sock to trigger docker to start and start its autostarting containers. If you don't have these types of containers you should be able to configure docker to autostart, but we don't want this by default.
If we want to get
There is one use case you are missing here. A docker.service configured to autostart via systemd while making sure the docker.socket is in place early. This is needed for containers that mount /var/run/docker.sock and use it to discover other running containers. See for example docker-gen or its usage in https://github.com/jwilder/nginx-proxy Docker has the annoying habit of creating /var/run/docker.sock/ directory when mounting the socket before it is created as it assumes a new host directory is to be mounted as a volume. This can prevent docker service from starting when combined with autostart containers. It is also almost impossible to fix as docker tools do not work (no daemon is running) and the daemon can't be started (because the directory is created during container autostart = before the proper socket device). Socket activation (pre-allocation) solves this nicely as the socket file is already present during the container autostart.
Are you saying docker creates/starts containers before listening on /var/run/docker.socket? If yes, then this is the bug.