Compose: docker-compose slow on docker for mac os beta

ping @frenchben :smile:

+1

got the same issue :D

@smith64fx problem also goes away if you turn off your WiFi?

@stijn Yes, when i turn off wifi everything works like charm

Von meinem iPhone gesendet

Am 05.05.2016 um 00:26 schrieb Sebastiaan van Stijn [email protected]:

@smith64fx problem also goes away if you turn off your WiFi?

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub

@smith64fx I see from your signature that you are likely from Germany (or Austria/switzerland). Do you mind me asking what is your Internet provider? I'm wondering if we have the same, and if it could be coming from the box which does not look like a very good piece of hardware/software and would not act as thought by docker.

(I am with Vodafone and I have their easybox-whatever)

Same issue on a wired network (corporate network), as soon as I un plug it everything is very fast. So I'm positive it is not related to you specific provider.

I've looked at the verbose output, there is no obvious error (nor anywhere in the system logs). Did notice this though:

With no networking, these lines are grouped together:

docker attach <- (u'd90162cbfd7b312c28488a209440641b2d9c9f99e8eb59082f20ddf7d84e7b7e', stderr=True, stream=True, stdout=True)
docker attach -> <generator object _multiplexed_response_stream_helper at 0x1045f20a0>
docker start <- (u'd90162cbfd7b312c28488a209440641b2d9c9f99e8eb59082f20ddf7d84e7b7e')

Without networking, I get ~100-200 lines of 'compose.parallel.feed_queue: Pending: set([])' between the attach <- and where it returns with attach -> ...

Before this point there is a lot more happening with network as well, but mostly just more calls to inspect image etc it seems.

I've attached the output of compose --verbose up for bot situations. The compose file is just two containers straight from the hub.

with-networking.txt
without-networking.txt

@holstvoogd oh, ok for the provider. Thanks for the info, I was a bit worried :)

@Erwyn @smith64fx To confirm, you're always connected (hard-wired) and at the same time use the same network with wifi?

@FrenchBen No it's only in the wifi network in my home. At my office it's super fast. But the thing is, everything else at home runs fast, except docker-compose ^_^"

@FrenchBen same as @smith64fx. It's only wifi at home so there is no wired connection involved. And as I can see @holstvoogd seems to have the same issue with a wired connection.

I am noticing the same issue with Docker for Mac Beta. docker-compose up is slow when Wifi is enabled, fast when Wifi is disabled.

• Docker Compose version: docker-compose version 1.7.1, build 0a9ab35
• Docker version: Docker version 1.11.1, build 5604cbe
• OS version: OS X El Capitan 10.11.4

Hi, Is there any news about this?

I have same issue. Compose/Docker/OSX versions are same as @eugenesia has.
I use WiFi at home and at office and at my home it works incredibly slow. At office it works as expected (fast).

I thought maybe it is something related to DNS server of my ISP (home and office internet providers are different) and I tried to use some public DNS including Google's one but it didn't help.

If I turn WiFi off then docker-compose works really fast

@KryDos A new release should be coming out this week with some speed improvements

I have the same issue, after updating to docker for mac 1.11.1-beta13, the problem persists. The workaround by switching the network(s) off and on again does not work anymore, the services start fast when switching the network off, but when switching the network on again, the services is no longer accessible and the docker daemon is not responding

docker ps
Error response from daemon: Bad response from Docker engine

• Docker Compose version: docker-compose version 1.7.1, build 0a9ab35
• Docker version: Docker version 1.11.1-beta13, build 7975
• OS version: OS X El Capitan 10.11.5

I've had the same issues, and found a post (sorry, lost the ref) mentioning docker-compose is trying to resolve localunixsocket.local. You can get insight into the dns lookup by running sudo tcpdump -A -s0 -nni en0 port 53

For now I've pointed localunixsocket.local to localhost in my /etc/hosts. Now everything is speedy again.

127.0.0.1 localunixsocket.local

Thanks @jewilmeer, that looks useful

I switched back using virtualbox with docker-machine. Problem doesn't exist and it's up to 10x faster than Docker Mac Beta!

@smith64fx please keep your comments constructive; it's a beta, it's not a finished product yet, so bugs and performance issues are expected. It's exactly these kind of issues that need reporting (and testing) to resolve them.

super awesome comment, @jewilmeer! For me I had to add a few more addresses to /etc/hosts which I discovered using your tcpdump command:

# (yours)
127.0.0.1 localunixsocket.local
# additional ones -- be sure to replace bracketed thing with the output of `hostname`
127.0.0.1 localunixsocket.home <my hostname>.home

After those additions -- speedy! Actually, amazingly speedy, seems a good bunch faster than when using Docker Toolbox! woop woop :) (Though that may be a highly subjective observation!)

That is pretty odd, but seems to point at what the underlying issue is...

I'm currently facing this same issue and I can't resolve the problem.
I've tried the previous suggestions for editing /etc/hosts. On our office network, docker is extremely slow. On home networks or using tethering to a cell phone removes all slow downs and everything is snappy.

We're using docker-compose with a web container linked to four service containers (postgres, redis, rabbitmq, elasticsearch). Connecting to any of the four service containers directly from OSX is fine. It's only slow when trying to connect from the web container to any of the service containers.

Running tcpdump -vvv -s 0 -l -n port 53 gives the following output when tethered to a cell phone

tcpdump: data link type PKTAP
tcpdump: listening on pktap, link-type PKTAP (Packet Tap), capture size 262144 bytes
16:54:34.236026 IP (tos 0x0, ttl 64, id 25341, offset 0, flags [none], proto UDP (17), length 69)
    172.20.10.4.56662 > 172.20.10.1.53: [udp sum ok] 5785+ PTR? 1.0.19.172.in-addr.arpa. (41)
16:54:34.239617 IP (tos 0x0, ttl 64, id 29137, offset 0, flags [none], proto UDP (17), length 123)
    172.20.10.1.53 > 172.20.10.4.56662: [udp sum ok] 5785 NXDomain* q: PTR? 1.0.19.172.in-addr.arpa. 0/1/0 ns: 19.172.IN-ADDR.ARPA. [1d] SOA 19.172.IN-ADDR.ARPA. . 0 28800 7200 604800 86400 (95)
16:54:34.303325 IP (tos 0x0, ttl 64, id 46188, offset 0, flags [none], proto UDP (17), length 69)
    172.20.10.4.58590 > 172.20.10.1.53: [udp sum ok] 52066+ PTR? 1.0.19.172.in-addr.arpa. (41)
16:54:34.309241 IP (tos 0x0, ttl 64, id 7329, offset 0, flags [none], proto UDP (17), length 123)
    172.20.10.1.53 > 172.20.10.4.58590: [udp sum ok] 52066 NXDomain* q: PTR? 1.0.19.172.in-addr.arpa. 0/1/0 ns: 19.172.IN-ADDR.ARPA. [1d] SOA 19.172.IN-ADDR.ARPA. . 0 28800 7200 604800 86400 (95)
16:54:39.309028 IP (tos 0x0, ttl 64, id 52570, offset 0, flags [none], proto UDP (17), length 69)
    172.20.10.4.63544 > 172.20.10.1.53: [udp sum ok] 12851+ PTR? 1.0.19.172.in-addr.arpa. (41)
16:54:39.320135 IP (tos 0x0, ttl 64, id 32359, offset 0, flags [none], proto UDP (17), length 123)
    172.20.10.1.53 > 172.20.10.4.63544: [udp sum ok] 12851 NXDomain* q: PTR? 1.0.19.172.in-addr.arpa. 0/1/0 ns: 19.172.IN-ADDR.ARPA. [1d] SOA 19.172.IN-ADDR.ARPA. . 0 28800 7200 604800 86400 (95)
16:54:39.392915 IP (tos 0x0, ttl 64, id 8082, offset 0, flags [none], proto UDP (17), length 69)
    172.20.10.4.59994 > 172.20.10.1.53: [udp sum ok] 22334+ PTR? 1.0.19.172.in-addr.arpa. (41)
16:54:39.416821 IP (tos 0x0, ttl 64, id 51863, offset 0, flags [none], proto UDP (17), length 123)
    172.20.10.1.53 > 172.20.10.4.59994: [udp sum ok] 22334 NXDomain* q: PTR? 1.0.19.172.in-addr.arpa. 0/1/0 ns: 19.172.IN-ADDR.ARPA. [1d] SOA 19.172.IN-ADDR.ARPA. . 0 28800 7200 604800 86400 (95)

and this is the output when on our office wifi:

16:54:13.870062 IP (tos 0x0, ttl 64, id 17811, offset 0, flags [none], proto UDP (17), length 69)
    192.168.0.32.56316 > 192.168.0.1.53: [udp sum ok] 21469+ PTR? 1.0.19.172.in-addr.arpa. (41)
16:54:13.870723 IP (tos 0x0, ttl 64, id 53920, offset 0, flags [none], proto UDP (17), length 69)
    192.168.0.32.52082 > 192.168.0.1.53: [udp sum ok] 50601+ PTR? 1.0.19.172.in-addr.arpa. (41)
16:54:13.872706 IP (tos 0x0, ttl 64, id 50395, offset 0, flags [none], proto UDP (17), length 69)
    192.168.0.32.56176 > 192.168.0.1.53: [udp sum ok] 45180+ PTR? 1.0.19.172.in-addr.arpa. (41)

So it looks like something with reverse DNS lookup but I'm unsure of how to troubleshoot. Disabling wifi completely guarantees this slowness as well. Disabling and re-enabling doesn't help.

Of course you find your own solution right after you post the question. It looks like an installed package in our dev environment updated DNS settings in OSX which cause the problem. Once I reset the OSX DNS to use the defaults in /etc/resolv.conf, everything works.

Could this be related to the issue with Bonjour 'owning' .local and an IPV6 bug?
details: https://news.ycombinator.com/item?id=11567442

Dunno if this helps but I used to have this issue and I fixed it by changing my DNS servers to 8.8.8.8 and 8.8.4.4.

Also this issue only happened on my Home network. At work I did not have this issue.

I am also facing the same issue even after trying @jewilmeer's fix.
docker-compose up works fine at my office network but it takes around ~7 mins at my home network.
same behavior with other docker-compose commands like stop, pull, ps etc.

docker --version
Docker version 1.12.0-rc2, build 906eacd, experimental

docker-compose --version
docker-compose version 1.8.0-rc1, build 9bf6bc6

docker-machine --version
docker-machine version 0.8.0-rc1, build fffa6c9

Not sure why but I had to remove any local domain element to make it work.

/etc/hosts:
127.0.0.1 localunixsocket

I have a very similar issue, but I think it may be related to my use of DNSCrypt?

@Erwyn I've experienced the same issue with Vodafone Easybox as well...
it turned out that Vodafone Easybox binds the search of .local domains to the router (to evaluate the dynamic hostname of your router, namely easy.box)
and my guess is that this binding was causing the docker-compose to wait for the response of the router (I might be completely wrong on this)...
but adding
127.0.0.1 localunixsocket.local to etc/hosts solved the issue for me

Hi guys,
127.0.0.1 localunixsocket to etc/hosts solved the issue for me

@davidino Thx Bro, works perfectly! I'm interested why we need this workaround?

Hello guys! Same problem here. In Brazil, using wifi in office it takes a long time to start. After changing the /etc/hosts files, everything worked fine.

Same issue here. Working out of one office (on WIFI) I have no problems or delays. Working out of a different office (also on WIFI) I would get ~10 minute delays.

Adding 127.0.0.1 localunixsocket to /etc/hosts did _not_ solve the issue for me. I tried doing that in combination with a reboot, but still no luck.

Adding 8.8.8.8 and 8.8.4.4 as DNS servers resolved the issue.

Thanks @Typositoire!

Hey, @dadarek, try to add 127.0.0.1 localunixsocket.home <hostname>.home in your hosts file. It just worked for me when I added both hostnames. So you can still using your local DNS, if you need...

This occurs for me both on the stable and beta channel, disconnecting internet or adding the host entry fixes it for me.

El Capitan 10.11.4
Docker version 1.12.0, build 8eab29e, experimental
docker-compose version 1.8.0, build f3628c7
docker-machine version 0.8.0, build b85aac1

I tried both hostname and disconnecting internet on a build command and nothing helps... tried the DNS change as well... it just sits there for 5-10 minutes and then starts the build process... I can see CPU utilization go up to 100% on docker-compose process

http://i.imgur.com/fmlhjCo.png

so frustrating

http://i.imgur.com/C1P6zHi.png

btw the setup worked fine with toolbox and ran very quickly...

with verbose debugging on I can see it hanging here

[ home/docker ] - $ docker-compose --verbose build app

compose.config.config.find: Using configuration files: ./docker-compose.yml
docker.auth.auth.load_config: File doesn't exist
compose.cli.command.get_client: docker-compose version 1.8.0, build f3628c7
docker-py version: 1.9.0
CPython version: 2.7.9
OpenSSL version: OpenSSL 1.0.2h 3 May 2016
compose.cli.command.get_client: Docker base_url: http+docker://localunixsocket
compose.cli.command.get_client: Docker version: KernelVersion=4.4.15-moby, Os=linux, BuildTime=2016-07-28T21:15:28.963402499+00:00, ApiVersion=1.24, Version=1.12.0, GitCommit=8eab29e, Arch=amd64, GoVersion=go1.6.3
compose.service.build: Building app
compose.cli.verbose_proxy.proxy_callable: docker build <- (pull=False, stream=True, nocache=False, tag=u'docker_app', buildargs=None, rm=True, forcerm=False, path='/Users/bartdabek/Sites/docker', dockerfile='Dockerfile-app')

after a few mins it goes to

docker.api.build._set_auth_headers: Looking for auth config
docker.api.build._set_auth_headers: No auth config in memory - loading from filesystem
docker.auth.auth.load_config: File doesn't exist
docker.api.build._set_auth_headers: No auth config found

then it hangs again...

my internet speed is fine just tested at 60mb/s

enabling Exclude simple hostnames from proxy settings worked perfectly for me.

NO_PROXY=* docker-compose up

Workaround posted by @jewilmeer
https://github.com/docker/compose/issues/3419#issuecomment-221793401 works for me.

It would be good to have tip by @jibingeo in Docker for Mac README.md or somewhere in tutorial.

Hello guys, @thaJeztah.

After going through source code, I found that socket.gethostbyname("localunixsocket") is taking more than 30s(in my case) to execute.

So I queried my local DNS and Google DNS

$ time nslookup localunixsocket 10.0.0.1
Server:     10.0.0.1
Address:    10.0.0.1#53

** server can't find localunixsocket: NXDOMAIN

real    0m30.295s
user    0m0.004s
sys     0m0.005s

$ time nslookup localunixsocket 8.8.8.8
Server:     8.8.8.8
Address:    8.8.8.8#53

** server can't find localunixsocket: NXDOMAIN

real    0m0.685s
user    0m0.005s
sys     0m0.013s

Local DNS works perfectly with FQDN hostname

time nslookup google.com 10.0.0.1
Server:     10.0.0.1
Address:    10.0.0.1#53

Non-authoritative answer:
Name:   google.com
Address: 216.58.196.110


real    0m0.028s
user    0m0.005s
sys 0m0.006s

This means actual issue is with router DNS.

Is it just me, or does doing a DNS lookup for localunixsocket seem counterintuitive? That seems like a filler hostname that's just used as a placeholder when something is expecting TCP-style addresses instead of local domain sockets.

At any rate, the difference in times between the local DNS and Google's DNS is interesting... I'd be curious what's causing it to do that. (sadly, I think you'd have to have another TCP dump on the DNS server pointed to by the router in order to tell, unless there's a tracert equivalent for DNS lookups that can preserve intermediate servers hit by a recursive query)

This might be informative as well (found in man nslookup on Mac OS X):

Mac OS X NOTICE

The nslookup command does not use the host name and address resolution
or the DNS query routing mechanisms used by other processes running on
Mac OS X. The results of name or address queries printed by nslookup
may differ from those found by other processes that use the Mac OS X
native name and address resolution mechanisms. The results of DNS
queries may also differ from queries that use the Mac OS X DNS routing
library.

Since they don't really give any clarification on what specific mechanism nslookup _does_ use vs. what Mac OS X provides, it's difficult to say whether Docker would be expected to share the behavior of nslookup, or that of other Mac OS X apps... (my guess would be that it uses the same methods nslookup does, but we'd probably have to dig into the code for both to figure that out definitively)

Hey @whitelynx

Here is the TCP dump taken with Local DNS and Google DNS. Command I used to take dump is

sudo killall -HUP mDNSResponder && docker-compose ps

With Local DNS:

15:49:30.025038 IP (tos 0x0, ttl 255, id 18504, offset 0, flags [none], proto UDP (17), length 83)
    10.0.0.3.60707 > 10.0.0.1.53: [udp sum ok] 54235+ PTR? lb._dns-sd._udp.0.0.0.10.in-addr.arpa. (55)
15:49:30.291508 IP (tos 0x0, ttl 255, id 36848, offset 0, flags [none], proto UDP (17), length 61)
    10.0.0.3.52331 > 10.0.0.1.53: [udp sum ok] 10799+ A? localunixsocket. (33)
15:49:31.097658 IP (tos 0x0, ttl 255, id 32568, offset 0, flags [none], proto UDP (17), length 83)
    10.0.0.3.60707 > 10.0.0.1.53: [udp sum ok] 54235+ PTR? lb._dns-sd._udp.0.0.0.10.in-addr.arpa. (55)
15:49:31.368098 IP (tos 0x0, ttl 255, id 54970, offset 0, flags [none], proto UDP (17), length 61)
    10.0.0.3.52331 > 10.0.0.1.53: [udp sum ok] 10799+ A? localunixsocket. (33)
15:49:33.596367 IP (tos 0x0, ttl 30, id 20508, offset 0, flags [none], proto UDP (17), length 133)
    10.0.0.1.53 > 10.0.0.3.60707: [udp sum ok] 54235 NXDomain* q: PTR? lb._dns-sd._udp.0.0.0.10.in-addr.arpa. 0/1/0 ns: 10.IN-ADDR.ARPA. [1d] SOA 10.IN-ADDR.ARPA. . 0 28800 7200 604800 86400 (105)
15:49:33.597103 IP (tos 0x0, ttl 30, id 20510, offset 0, flags [none], proto UDP (17), length 136)
    10.0.0.1.53 > 10.0.0.3.52331: [udp sum ok] 10799 NXDomain q: A? localunixsocket. 0/1/0 ns: . [2h8m4s] SOA a.root-servers.net. nstld.verisign-grs.com. 2016090900 1800 900 604800 86400 (108)

With Google DNS:

15:45:25.301293 IP (tos 0x0, ttl 255, id 37492, offset 0, flags [none], proto UDP (17), length 83)
    10.0.0.3.60707 > 8.8.8.8.53: [udp sum ok] 14029+ PTR? lb._dns-sd._udp.0.0.0.10.in-addr.arpa. (55)
15:45:25.371167 IP (tos 0x0, ttl 56, id 10269, offset 0, flags [none], proto UDP (17), length 83)
    8.8.8.8.53 > 10.0.0.3.60707: [udp sum ok] 14029 NXDomain q: PTR? lb._dns-sd._udp.0.0.0.10.in-addr.arpa. 0/0/0 (55)
15:45:25.599570 IP (tos 0x0, ttl 255, id 7256, offset 0, flags [none], proto UDP (17), length 61)
    10.0.0.3.59912 > 8.8.8.8.53: [udp sum ok] 3154+ A? localunixsocket. (33)
15:45:25.702374 IP (tos 0x0, ttl 56, id 39895, offset 0, flags [none], proto UDP (17), length 136)
    8.8.8.8.53 > 10.0.0.3.59912: [udp sum ok] 3154 NXDomain q: A? localunixsocket. 0/1/0 ns: . [29m58s] SOA a.root-servers.net. nstld.verisign-grs.com. 2016090900 1800 900 604800 86400 (108)

Here I can see ~3sec delay with Local DNS.

Note: Router I used here is different than one I used for previos comment

Hi all,
after the upgrade to docker for mac Version 1.12.1 (build: 12133) i had to add the
127.0.0.1 localunixsocket again in the /etc/hosts

I had to do what davidino did as well.

No estimative on solving this very annoying bug?

I just had to also add 127.0.0.1 localunixsocket.lan to make it work. I'm using macOS Sierra.

I do not really know if this is the same problem, but the reply of @jibingeo helped me.
_docker-compose_ is also very slow in my company environment using Docker Toolbox for Windows. Configuring NO_PROXY=* helped me too but this interferes with my company proxy. So I tried a little bit and I found a more specific solution (assuming you are using the default docker VirtualBox ip range 192.168.99.0/24):

NO_PROXY=192.168.99.0/24 speeds up everything, so compose doesn't need to try my company proxy for internal IPs.

Related? https://github.com/SeleniumHQ/docker-selenium/issues/227

@davidino solution of putting 127.0.0.1 localunixsocket in your /etc/hosts resolved the issue for me.

So much faster now

I'm having the same issues. I've tried turning off my wifi, adding multiple entries to my host file to no success. I have tried the same setup on my linux box and the results are much faster.

The build seems to run at a decent speed but once I make any requests into the running containers the result is horrible. About 30 seconds for any request, no matter if it is even a simple text response.

I'm running Mac OS Sierra (10.12.1) and Docker for Mac (1.12.1) with a Rails stack.

I'm on 10.11.6 (15G31)

This is what's in my /etc/hosts file:

##
# Host Database
#
# localhost is used to configure the loopback interface
# when the system is booting.  Do not change this entry.
##
255.255.255.255 broadcasthost
::1             localhost 
127.0.0.1 localhost
127.0.0.1 localunixsocket
127.0.0.1 localunixsocket.lan
127.0.0.1 localunixsocket.local

I am on beta channel docker 1.12.3-beta29.2 (13499)

@gardner I've added that to my hosts file and I have tried the beta with no success. I'm really starting to think it's something to do with Sierra. I'm pretty sure it was working before I upgraded. I'm going to give the beta another try to see if it works. I'll post again after I test.

@gardner Same issue. Now running Docker 1.12.3-beta29.3 (13640). My linux setup is still running it way faster with 1/4th of the RAM.

The best I can tell is that it's an IO issue between docker and the host machine. I ran a flamegraph on the request and it's spending most of it's time reading files.
https://www.dropbox.com/s/4702tx7qqpkr4yd/Screenshot%202016-11-02%2014.39.22.png?dl=0

This is the same app, same request, running locally.
https://www.dropbox.com/s/xxs5jdug7cllpbu/Screenshot%202016-11-02%2014.44.37.png?dl=0

If I configure configure the app to run in production mode it runs just as fast inside of Docker.

Not sure if this is already known or not but hopefully it helps anyone else coming to this thread trying to figure it out.

Edit: Seems like this is the real issue I'm running up against. https://forums.docker.com/t/file-access-in-mounted-volumes-extremely-slow-cpu-bound/8076/223

Also running into this issue, the changes to hosts makes a little bit of a difference, but still a bit sluggish.
127.0.0.1 localunixsocket.local 127.0.0.1 localunixsocket

I'm seeing this on the following stable docker version running OSX 10.11.6 with the following docker version:

Client:
 Version:      1.12.3
 API version:  1.24
 Go version:   go1.6.3
 Git commit:   6b644ec
 Built:        Wed Oct 26 23:26:11 2016
 OS/Arch:      darwin/amd64

Server:
 Version:      1.12.3
 API version:  1.24
 Go version:   go1.6.3
 Git commit:   6b644ec
 Built:        Wed Oct 26 23:26:11 2016
 OS/Arch:      linux/amd64

I'm seeing this on a slow cloud connection (The Cloud in a cafe in London), when I turn WiFi off, compose is super quick, otherwise everything runs very slowly...

Did the latest release (1.9.0) seem to change anything for people experiencing the issue?

@shin- I've still got 1.8.1 in my docker-compose --version with the latest Docker for Mac. When can we expect an update?

When can we expect resolution for this issue?

1.9 is in the beta channel, not sure when it will ship in stable, probably
in a week or so.

On 18 Nov 2016 8:07 a.m., "David Richards" notifications@github.com wrote:

@shin- https://github.com/shin- I've still got 1.8.1 in my docker-compose
--version with the latest Docker for Mac. When can we expect an update?

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/docker/compose/issues/3419#issuecomment-261472095,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAdcPBV7gMv0kMwil0SEz3etChNY6ej3ks5q_VyugaJpZM4IXnGd
.

For me McAfee Endpoint Security was the reason for docker-compose being very slow. Seems like the on-access scanner is really killing the the performance of unpacking the python environment that seems to happen every time docker-compose is executed.

For me, removing the .local search domain made all the difference.

@shin- in the 1.9.0-rc4 I still have the issue. I don't know, what I did, but some days ago I didn't have the issue, using docker-compose for over a year.
docker-compose --version is really fast
docker-compose ps is very slow
Disabling Wifi - ps is fast, too

@gsong unfortunately that didn't help for me

I also suddenly started having this issue. Just like @timsuchanek I have been using docker-compose for about a year now and docker-compose up hangs almost indefinitely. Like everyone else, when I switch off wifi it works.

I am on docker-compose version 1.9.0, build 2585387

Edit: Adding 127.0.0.1 localunixsocket to /etc/hosts fixed it for now. I am on macOS 10.11.6

What are the chances this is due to the .local changes introduced in yosemite?

https://support.apple.com/en-us/HT203136
https://news.ycombinator.com/item?id=9026192

I saw that @afxjzs mentioned it earlier but didn't see any follow up.

I stumbled on something that works for me, while trying to get xdebug working:

sudo ifconfig en0 alias 10.254.254.254 255.255.255.0

on the host machine.

Thanks to James Cowie.

Edit: It looks like xdebug was the root of my problem. With xdebug turned off, my docker machine is super-fast, even with /etc/hosts in its default state. With it turned on, and my xdebug.remote_host set to 10.254.254.254, it slows down to a crawl. The suggested edits to /etc/hosts don't help, but setting the localhost alias on en0 as above fixes the problem.

This is happening to me with the latest stable Docker for Mac (1.13.1, docker-compose 1.11.1)

Doing NO_PROXY=* works.

This happened to me with latest update too (1.13.1, docker-compose 1.11.1). https://github.com/docker/compose/issues/3419#issuecomment-221793401 resolved my issue.

I have the same error. Adding localunixsocket to /etc/hosts. did not work. Temporary fix marking the Exclude simple hostnames in proxies tab.

macOS Sierra 10.12.3 (16D32)
Docker version 1.13.1, build 092cba3
docker-compose version 1.11.1, build 7c5d5e4

I've noticed that any non-responsive search domains make for very slow docker-compose. It's not just .local I was using .dev.

I encountered the same problem today with docker-compose hanging forever even to display help or --version. I followed @jewilmeer advice about using tcpdump and in my case problem was solved by adding 127.0.0.1 prod.python.map.fastly.net to /etc hosts

Pretty weird, I think?

Same issue here. It looks like it hangs twice, each for about 25 seconds. Here's the --verbose output with each HANG interjected

compose.config.config.find: Using configuration files: ./config/docker-compose-dev.yml
docker.auth.find_config_file: Trying paths: ['/Users/dorkusprime/.docker/config.json', '/Users/dorkusprime/.dockercfg']
docker.auth.find_config_file: Found file at path: /Users/dorkusprime/.docker/config.json
docker.auth.load_config: Found 'auths' section
docker.auth.parse_auth: Found entry (registry=u'https://index.docker.io/v1/', username=u'dorkusprime')

[HANGS FOR ~25S]

compose.cli.command.get_client: docker-compose version 1.11.2, build dfed245
docker-py version: 2.1.0
CPython version: 2.7.12
OpenSSL version: OpenSSL 1.0.2j  26 Sep 2016
compose.cli.command.get_client: Docker base_url: http+docker://localunixsocket
compose.cli.command.get_client: Docker version: KernelVersion=4.9.13-moby, Arch=amd64, BuildTime=2017-03-15T20:28:18.193664702+00:00, ApiVersion=1.27, Version=17.03.1-ce-rc1, MinAPIVersion=1.12, GitCommit=3476dbf, Os=linux, Experimental=True, GoVersion=go1.7.5
compose.project.build: mongodb uses an image, skipping
compose.project.build: redis uses an image, skipping
compose.service.build: Building web
compose.cli.verbose_proxy.proxy_callable: docker build <- (pull=False, stream=True, nocache=False, tag='dorkusprime/dashboard-test', buildargs=None, rm=True, forcerm=False, path='/Users/dorkusprime/repository/Dashboard-test', dockerfile=None)
docker.api.build._set_auth_headers: Looking for auth config
docker.api.build._set_auth_headers: Sending auth config (u'https://index.docker.io/v1/')

[HANGS FOR ~25S]

compose.cli.verbose_proxy.proxy_callable: docker build -> <generator object _stream_helper at 0x105cc4910>

I tried the /etc/hosts workarounds with no noticeable improvement.

Same issue here and no solution from the whole thread helps me (neither /etc/hosts nor NO_PROXY variable nor Exclude simple hostnames nor changing DNS to 8.8.8.8).

One thing to note: if I run docker with sudo, it solves the speed issue.

Latest docker version (Docker version 17.03.1-ce-rc1, build 3476dbf). I tried both beta and stable releases.

docker --version takes 32 seconds to output the version in my case.

This problem has been around for almost a year now...

@mobileka Are you talking about docker or docker-compose?

@shin- In my case every single cli command (be it docker or docker-compose) related to docker has a latency of 30 or so seconds before actually giving results or before starting doing its job.

@mobileka Okay - that's definitely unrelated to the problem that is described here. Consider creating an issue on the Docker for Mac repo instead.

@shin- Sorry, I didn't realize that I'm in a wrong repo because the "symptoms" were very similar: it's slow when internet connection is active and it's fast when there's no internet connection.

Thank you, I'll create an issue in the Docker for Mac repo.

On the off chance that this hits anyone else, I'm pretty sure that my playing around (and subsequent screwing up) with Consul added a config file in /etc/resolvers. This caused issues similar to @seeekr reported with seeing localunixsocket., like so:

A.D.*.5.>t.d............localunixsocket.foo.bar.example.com.....
14:36:13.357925 IP 10.23.45.67.65066 > 10.98.76.54.53: 25754+ A? localunixsocket.foo.bar.example.com. (54)
E..R.......P
...

Removing the file from /etc/resolvers solved the issue immediately.

Hope that helps!

Same issue here and no solution from the whole thread helps me (neither /etc/hosts nor NO_PROXY variable nor Exclude simple hostnames nor changing DNS to 8.8.8.8).

I write a toy website(logic is really simple and should have no performance problems) and run it locally using docker-compose. It turns out almost every page takes minutes to load. Any instruction?

@mqliang page load times of your app seem entirely unrelated to this issue, and unrelated to Compose in general.

MacOS Sierra, 10.12.5.
Docker Community Edition
Version 17.06.0-ce-mac18 (18433)
Channel: stable
d9b66511e0

I already had DNS as 8.8.8.8. Needed to add both localunixsocket.local and localunixsocket into /etc/hosts. The instant this was added my running docker-compose sprang to life.

Im not sure if this helps anyone - but I have dnscrypt installed and after switching to docker beta, docker compose was incredibly slow. Reinstalling dnscrypt (via brew cask) fixed the problem for me.

I love you @jewilmeer

Just wanted to leave this here. My problems was session files inside my build context. The files were owned by apache user and docker-compose build would just hang after this line:

docker.api.build._set_auth_headers: No auth config found 

Saddest thing is that I've stopped using file based sessions a long time ago. Should probably clean my workspace now and then.

The reason for commenting: It would be really nice if compose would not just hang. I only found out the culprit using docker build directly which nicely informed me of my problems.

@paali can you elaborate on what you did exactly?

@Vad1mo my full setup is quite complex (and messy and in progress) but the basic parts are Symfony2 project. Had old session files on ./app/sessions folder that were owned by apache user (before docker times).

Basically I had
COPY app app/
on on of the Dockerfiles and docker-compose.yml to build the perticular Dockerfile.
The command used:
docker-compose -f docker-compose-ci.yml build --no-cache --force-rm

As noted the build process never really started but froze after the lines about auth headers. Doing build on docker directly gave me:

> docker build -f thefile --no-cache --force-rm
error checking context: 'no permission to read from '/path/to/my/project/app/sessions/sess_n8turtujft1bipv745khqsqbi1''.

Next time I'll know to try docker directly right away but nothing really seemed to hint what the real issue was. I'm on Docker for Mac 7.06.1-ce-mac24.

Any word on a real solution to this other than having to tell everyone to add a host rule or turn off proxies?

+1

+1

+1

What fixed it for me was going to my System Preferences / Network / Advanced / DNS / Search Domains, and removing the entry ".local." which I had put there. This caused the macOS to populate the Search Domains only with the default value, "localdomain". And then docker-compose became responsive again.

docker itself was responsive all the time.

I don't know, but I would guess that perhaps docker is correctly finding an on-system resource using an IP address or a stable local name, while docker-compose is unsafely relying on localdomain always being defined as one of the search domains. But I dunno!

I'd run the line to monitor dns that was in the original post on the fix:

sudo tcpdump -A -s0 -nni en0 port 53

That showed me that what I needed to add to my hostfile was:

127.0.0.1 localunixsocket.localdomain

seems something changed from .local to .localdomain?

I have since done a fresh install of 10.12 Sierra. I reinstalled docker and could not reproduce the issue.

I ran in to this issue today, my first day on Mac.
Docker compose was just stalled, literally after inserting the line in to the /etc/hosts it started working as expected.
I was using WiFi, everyone in the office with same version on Ethernet never even heard of this issue.
Docker: Version 17.09.0-ce-mac35 (19611)
Mac 10.13.1 (17B48)

Same bug here. I have to add in the three lines to /etc/hosts to solve this problem.
127.0.0.1 localunixsocket
127.0.0.1 localunixsocket.lan
127.0.0.1 localunixsocket.local

Same bug. This worked for me.

$ sudo tcpdump -vvv -s 0 -l -n port 53
...
13:46:10.203734 IP (tos 0x0, ttl 255, id 7224, offset 0, flags [none], proto UDP (17), length 81, bad cksum 0 (->7b21)!)
    10.64.14.244.54683 > 10.0.0.10.53: [bad udp cksum 0x2491 -> 0xf39b!] 30038+ A? localunixsocket.*.svc.cluster.local. (53)

$ sudo vim /etc/hosts

# hacks for docker
127.0.0.1 localunixsocket.*.svc.cluster.local

I added 127.0.0.1 localunixsocket in /etc/hosts and it worked for me, thanks !
(but it is still a wtf bug)

Still a problem on the latest version. The above fixes don't seem to do anything for me, at some point it just gets so slow that it hangs. The workaround for me is to restart Docker for mac every so often.

Confirmed that 127.0.0.1 localunixsocket in /etc/hosts dramatically speeds things up, please fix!

adding 127.0.0.1 localunixsocket in /etc/hosts helps. I'm using docker-compose version 1.18.0, build 8dd22a9

The solution @norbertsienkiewicz recommended worked perfectly for me. It dropped my docker-compose up time from over 10 minutes down to less than a minute (version 1.18.0).

I'm actually more curious as to why this started happening in the first place. It seems a bit silly to me for me to have to modify my hosts file as a workaround to a problem that was recently introduced and have it declared to be the "solution".

Here is the backtrace that causes the spurious DNS lookup:

  File "/Library/Python/2.7/site-packages/docker-3.1.0-py2.7.egg/docker/api/daemon.py", line 88, in info
    return self._result(self._get(self._url("/info")), True)
  File "/Library/Python/2.7/site-packages/docker-3.1.0-py2.7.egg/docker/utils/decorators.py", line 46, in inner
    return f(self, *args, **kwargs)
  File "/Library/Python/2.7/site-packages/docker-3.1.0-py2.7.egg/docker/api/client.py", line 193, in _get
    return self.get(url, **self._set_request_timeout(kwargs))
  File "/Library/Python/2.7/site-packages/requests-2.18.4-py2.7.egg/requests/sessions.py", line 521, in get
    return self.request('GET', url, **kwargs)
  File "/Library/Python/2.7/site-packages/requests-2.18.4-py2.7.egg/requests/sessions.py", line 499, in request
    prep.url, proxies, stream, verify, cert
  File "/Library/Python/2.7/site-packages/requests-2.18.4-py2.7.egg/requests/sessions.py", line 672, in merge_environment_settings
    env_proxies = get_environ_proxies(url, no_proxy=no_proxy)
  File "/Library/Python/2.7/site-packages/requests-2.18.4-py2.7.egg/requests/utils.py", line 692, in get_environ_proxies
    if should_bypass_proxies(url, no_proxy=no_proxy):
  File "/Library/Python/2.7/site-packages/requests-2.18.4-py2.7.egg/requests/utils.py", line 676, in should_bypass_proxies
    bypass = proxy_bypass(netloc)
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/urllib.py", line 1487, in proxy_bypass
    return proxy_bypass_macosx_sysconf(host)
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/urllib.py", line 1453, in proxy_bypass_macosx_sysconf
    hostIP = socket.gethostbyname(hostonly)

I just had this problem after switching from wireless to wired. Back to wireless and all is right with the world.

Are the changes to /etc/host to the host machine or the docker container??

Which hosts file to modify ?

1. macOS hosts file ?
2. The Linux VM serving as docker host ?
3. The container itself ?

Not sure why but I had to remove any local domain element to make it work.

/etc/hosts:
127.0.0.1 localunixsocket

Genius!!!