Bug 1192848 - docker no longer supports socket-activation
Summary: docker no longer supports socket-activation
Alias: None
Product: Fedora
Classification: Fedora
Component: docker
Version: 22
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: Daniel Walsh
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2015-02-15 23:05 UTC by Tim Cuthbertson
Modified: 2016-06-03 12:38 UTC (History)
17 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2016-06-03 12:38:19 UTC
Type: Bug

Attachments (Terms of Use)

Description Tim Cuthbertson 2015-02-15 23:05:55 UTC
Version-Release number of selected component (if applicable):

How reproducible:

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>
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>

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.

Comment 2 Fedora Admin XMLRPC Client 2015-03-24 03:37:55 UTC
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Comment 3 Lokesh Mandvekar 2015-04-27 17:52:19 UTC
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.

Comment 4 Tim Cuthbertson 2015-04-28 02:02:13 UTC
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).

Comment 5 Daniel Walsh 2015-04-28 13:07:00 UTC
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.

Comment 6 Daniel Walsh 2015-06-02 20:52:55 UTC
If we want to get

Comment 7 Martin Sivák 2016-04-04 07:43:46 UTC
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.

Comment 8 Daniel Walsh 2016-04-04 13:16:36 UTC
Are you saying docker creates/starts containers before listening on /var/run/docker.socket?  If yes, then this is the bug.

Note You need to log in before you can comment on or make changes to this bug.