Fixed by just adding the Unit.

/usr/lib/systemd/system/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

https://github.com/docker/docker/blob/master/contrib/init/systemd/docker.socket

@lcamilo15 solution works for FC 22

wget https://raw.githubusercontent.com/docker/docker/master/contrib/init/systemd/docker.socket -O /usr/lib/systemd/system/docker.socket systemctl daemon-reload systemctl start docker.socket systemctl start docker

This is still an issue. Why is this bug closed?

@adrianovieira did you run systemctl daemon-reload after changing the file?

I was able to get around this issue temporarily by copying /usr/lib/systemd/system/docker.socket from a different vm which was still running rc4.

Top google hit on “docker systemd” gets you this page:

https://docs.docker.com/engine/admin/systemd/

Which explicitly states in it’s documentation to put “-H fd://” into your systemd drop in file. This is why so many RHEL users broke with the 1.12 install: Docker’s own Docks state to put that in the file which was subsequently removed. To further compound the issue, because the file exists, it will NOT get overwritten/removed in the upgrade…meaning anyone who’s followed those instructions in the past will have a broken docker after yum upgrade…

Big old warnings about “fd://” being removed for RHEL/RPM distributions should be ALL OVER that page.

Finding the documentation that this feature was removed was practically impossible as well.

Just experienced the same issue with 1.12 in CentOS 7. Funny, I can use my existing /usr/lib/systemd/system/docker.service IF I do the following

rpm -e docker-engine

rpm -e docker-engine-selinux

yum -y install docker-engine

The problem is when I take a stock CentOS 7 system, and then do yum -y install docker-engine, I run into the problem. Why does removing and re-adding the same package solve the problem? To me, this sounds a bit like configuration issue with the new 1.12 RPM configuration.

@theonlydoo the socket file is no more provided in the docker package (1.12 and later) – it should look like this : https://github.com/docker/docker/blob/master/contrib/init/systemd/docker.service.rpm.

You can look at https://github.com/docker/docker/pull/24804 for reason what it was removed.

However, there is another motivation for removing socket activation from docker’s systemd files and that is because when you have daemons running with --restart always whenever you have a host reboot those daemons will not be started again because the docker daemon is not started by systemd until a request comes into the docker API.

The immediate workaround should be to remove the Requires=docker.socket line in the docker.service file if it’s still there 👼.

I’ve got the same issue after this morning’s release. I’ve tried to uninstall docker :

# curl -sSL get.docker.io | sh
+ sh -c 'sleep 3; dnf -y -q install docker-engine'
setsebool:  SELinux is disabled.
Re-declaration of boolean virt_sandbox_use_fusefs
Failed to create node
Bad boolean declaration at /var/lib/selinux/targeted/tmp/modules/100/virt/cil:148
/usr/sbin/semodule:  Failed!

If you would like to use Docker as a non-root user, you should now consider
adding your user to the "docker" group with something like:

  sudo usermod -aG docker your-user

Remember that you will have to log out and back in for this to take effect!

I’m on Fedora 24, with selinux disabled

@Illydth by default, the client look on unix socket in /var/run/docker.sock, that’s why with -H unix:///docker/docker.sock it won’t work without setting DOCKER_HOST. If you use -H unix:///var/run/docker.sock it will work fine.

The breaking change here is that using fd:// doesn’t work anymore if Requires=docker.socket (which is now by default). I think we should update the documentation to reflect that. @crosbymichael @thaJeztah wdyt ?

This should be fixed on master, and will be included in 1.12-GA; to fix this issue, change the docker unit file as is done in this PR: https://github.com/docker/docker/pull/25094

Try to create /usr/lib/systemd/system/docker.socket if missing and/or rm /var/lib/docker as well as /var/run/docker.

@EtienneK looks like there’s an open issue for that; https://github.com/docker/machine/issues/3632

Update: So the base docker systemd files work just fine, however when I drop the following systemd drop in file in place I get:

[root@test docker.service.d]# docker ps
Cannot connect to the Docker daemon. Is the docker daemon running on this host?

The Systemd drop in file (As per documentation here: https://docs.docker.com/engine/admin/systemd/) looks like the following:

[root@stldbldtst01 docker.service.d]# cat `pwd`
cat: /etc/systemd/system/docker.service.d: Is a directory
[root@stldbldtst01 docker.service.d]# cat ./docker-service.conf
[Service]
EnvironmentFile=-/etc/sysconfig/docker
EnvironmentFile=-/etc/sysconfig/docker-storage
EnvironmentFile=-/etc/sysconfig/docker-network
ExecStart=
ExecStart=/usr/bin/docker daemon $OPTIONS \
    $DOCKER_STORAGE_OPTIONS \
    $DOCKER_NETWORK_OPTIONS \
    $BLOCK_REGISTRY \
    $INSECURE_REGISTRY

Had to remove the “-H fd://” from the documented drop in file option or I’d get the daemon fail to start again.

Help? What’s wrong with the systemd drop in file that’s causing the system not to be accessible from “docker ps” at the command line?

The docker environment files referenced are as follows:

/etc/sysconfig/docker: OPTIONS="-g /docker" /etc/sysconfig/docker-storage DOCKER_STORAGE_OPTIONS="-s btrfs" /etc/sysconfig/docker-network DOCKER_NETWORK_OPTIONS="-H tcp://0.0.0.0:2375 -H unix:///docker/docker.sock"

The final command line for dockerd comes out as follows: dockerd -g /docker -s btrfs -H tcp://0.0.0.0:2375 -H unix:///docker/docker.sock

(NOTE: Yes I am aware this is a totally open / unsecured installation, no i’m not planning on going to production with this, yes this is on an isolated sandbox.)

I’ve tracked the problem down to the Networking Options…is there something about 1.12’s ability to use -H tcp://0.0.0.0:2375 -H unix:///docker/docker.sock?

Update:

So I’ve tracked this down: Apparently with the removal of “fd://” as an option on RHEL we’re down to 3 methods to connect to docker:

• Whatever method local users connect to docker with by default if you specify no networking options.
• TCP://
• UNIX://

The problem seems to be that turning on ANY Networking options (Such as TCP://) DISABLES whatever the local connection method is…if dockerd is loaded with -H tcp://0.0.0.0:2375, all users will get “Cannot connect to the Docker daemon. Is the docker daemon running on this host?” unless they have “DOCKER_HOST” set.

This was NOT the case when docker was capable of being used with the “fd://” option to use systemd sockets, but since this has been removed, significant functionality for RHEL has been impared.

Is there a solution to this other than “too bad, you should have been using Ubuntu”?

Upgrade to the latest this morning, the package still doesnt provides the socket that @lcamilo15 mentioned and docker still wont start. @crosbymichael the issue mentioned in journalctl is the exact same that is workaround by @lcamilo15. For me the immediate workaround was to rollback to the previous version of docker.

Actually I only “comment” that line. Now I removed it and everything is ok.