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

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

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

[UPDATE]: Or set env variable NO_PROXY to some value.

NO_PROXY=* docker-compose up

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

/etc/hosts: 127.0.0.1 localunixsocket

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

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

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

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

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

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’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”.

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

@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

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.

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

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

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

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

No estimative on solving this very annoying bug?

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.

ping @frenchben 😄

+1

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

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

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

@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 notifications@github.com:

@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

Which hosts file to modify ?

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

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

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

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

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

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)

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.

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

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!

+1

+1

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.

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

@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

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

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)

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

got the same issue 😄

+1