docker-tcp.socket fails on each reboot

196 views
Skip to first unread message

Pan Cake

unread,
Jul 11, 2016, 8:37:14 PM7/11/16
to CoreOS User
I'm on CoreOS stable (1010.6.0).
Whenever I reboot the droplet (I'm on DigitalOcean), I always get this error message:


Failed Units: 1
    docker
-tcp.socket

Then if I issue:

journalctl
-b -u docker-tcp.socket
-- Logs begin at Fri 2016-06-17 18:51:06 UTC, end at Fri 2016-07-08 06:42:55 UTC. --
Jul 08 06:33:24 coreos-512mb-nyc2-01 systemd[1]: docker-tcp.socket: Failed to listen on sockets: Cannot assign requested address
Jul 08 06:33:24 coreos-512mb-nyc2-01 systemd[1]: Failed to listen on Docker Socket for the API.
Jul 08 06:33:24 coreos-512mb-nyc2-01 systemd[1]: docker-tcp.socket: Unit entered failed state.
Jul 08 06:33:24 coreos-512mb-nyc2-01 systemd[1]: docker-tcp.socket: Failed to listen on sockets: Cannot assign requested address
Jul 08 06:33:24 coreos-512mb-nyc2-01 systemd[1]: Failed to listen on Docker Socket for the API.

I followed the procedure to enable the docker-tcp socket here:
https://coreos.com/os/docs/latest/customizing-docker.html

For now, if I stop docker.service manually, and start docker-tcp.socket first, then I can start docker.service without any problem. But, I must do this after each reboot, which is not terrible.

I would like to fix this error, so that my droplet boots correctly (and the docker-tcp.socket gets started without any error).

Here's my docker-tcp.socket:


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

[Socket]
ListenStream=172.17.0.1:2375
BindIPv6Only=both
Service=docker.service

[Install]
WantedBy=sockets.target


Here's my docker.service:

[Unit]
Description=Docker Application Container Engine
Documentation=http://docs.docker.com
After=docker.socket early-docker.target network.target
Requires=docker.socket early-docker.target

[Service]
Environment="DOCKER_CGROUPS=--exec-opt native.cgroupdriver=systemd"
EnvironmentFile=-/run/flannel_docker_opts.env
MountFlags=slave
LimitNOFILE=1048576
LimitNPROC=1048576
ExecStart=/usr/lib/coreos/dockerd daemon --host=fd:// --insecure-registry 0.0.0.0:5000 $DOCKER_OPTS $DOCKER_CGROUPS $DOCKER_OPT_BIP $DOCKER_OPT_MTU $DOCKER_OPT_IPMASQ

[Install]
WantedBy=multi-user.target



What's wrong with my setup, and how would I ensure that docker-tcp.service gets loaded before docker.service?

Note: I have no cloud-config file for now.  I'm just building "manually" to see how things go.


Thanks!


Rob Szumski

unread,
Jul 12, 2016, 10:51:58 AM7/12/16
to Pan Cake, CoreOS User
Try adding a Requires=docker.service in your TCP unit and see if that clears it up. This should better control your order by making the Before= take affect.
--
You received this message because you are subscribed to the Google Groups "CoreOS User" group.
To unsubscribe from this group and stop receiving emails from it, send an email to coreos-user...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Pan Cake

unread,
Jul 12, 2016, 5:58:46 PM7/12/16
to CoreOS User
Thanks Rob,

I added:
Requires=docker.service

to my docker-tcp.socket, ran sudo systemctl daemon-reload, and rebooted.
Same error again  :(


I also tried adding, instead, this:
Requires=docker-tcp.socket
After=docker-tcp.socket

to my docker.service file.  After reloading the config and rebooted, again, same error!

This is weird...

Pan Cake

unread,
Jul 12, 2016, 6:06:18 PM7/12/16
to CoreOS User
I think I have a hint...

Usually, and according to the docs, most people do this, for the docker-tcp.socket:
ListenStream=2375




But I decided to do THIS, instead:
ListenStream=172.17.0.1:2375


172.17.0.1.....   Isn't that the default virtual network IP assigned by Docker itself?
Maybe that's the exact reason why I'm getting this error message?
docker-tcp.socket: Failed to listen on sockets: Cannot assign requested address



It seems like I'm trying to assign an address that doesn't exist yet...
Possible?


Note: The reason why I don't like ListenStream=2375  is because I'm opening the port to the whole planet...
I got my droplet hacked, on DigitalOcean, because of that...


Reply all
Reply to author
Forward
0 new messages