Timed out while waiting for Docker daemon to be ready #2302
Comments
|
Just uninstalled Docker and Installed it again as I had the same problem as above. I still have actually after the reinstall. Windows 10 as well (latest version). Timed out while waiting for Docker daemon to be ready |
|
I'm having the same issue since upgrading to the most recent version. |
|
Same problem here.
Problem persists even after factory reset, and also a full uninstall / re-install of docker. crash report ID: E3848FD7-05DB-4B46-8A92-C76B6CCA34F9/20180730152328 |
|
Try to roll back the Windows update. That solved this issue for me.. |
|
Which Windows update? I tried several restore points none of them worked for me. |
|
@reecebradley Where did you find the old version? |
|
I had it lying around in my Downloads folder. However, I remember a situation like this in the past, you might find an answer in this Issue |
|
@reecebradley I found another way of getting an older version. Install Chocolatey if you don't have it yet ( https://chocolatey.org/) and then in an elevated powershell prompt run "Choco list docker-for-windows --all" to see all versions available and run for example "Choco install docker-for-windows -version 18.03.1.17513" to install the mentioned version, make sure you uninstall the version you don't want first. |
|
Yeah I had to roll back to the previous version too, so i can work again. It's a shame though because I was looking forward to the new ability in this release to mount named pipes on windows. I hope this can be fixed soon so I can upgrade :-) |
|
same here Version: 18.06.0-ce-win72 (19098) |
|
Same here, I did factory reset and uninstall re-install but still have problem. |
|
Still having this problem. It's Docker for Windows crashing, the Docker service keeps running but, with a very high cpu (up to 37%) and the memory usage is enormous: 10Gb. While there is actually nothing to do. |
|
I have this issue as well |
|
Maybe the issue is fixed now, it started up and seems stable even though I'm on edge: Confirm anyone else? |
|
One thing that worked for a colleague was to reset WinRM. If you are still experiencing this problem, please provide the output of |
|
The solution provided here: #2353 (comment) worked out for me |
On windows 10 latest update: However: So I set the network connection profiles from "public" to "private" following this: http://www.hurryupandwait.io/blog/fixing-winrm-firewall-exception-rule-not-working-when-internet-connection-type-is-set-to-public Now Tried to start docker again now that
|
|
Same, Crash ID 8E976C42-DB00-4C9F-B535-31A3CCA349E0/20180905142927 WinRM qc reports I'd reset the hyper-v switch networks to be private to get WinRM to work via |
|
Also #2289 is probably the same. |
|
I think I know what's causing this. It took me forever to figure it out on my machine. Can someone, or even several, of you guys reply with the output from these four Powershell commands, please? Be sure to run as admin. We'll see if we can get this fixed. Thanks.
|
|
|
This is after I uninstalled, because it was just getting too irritating. Let me know if you want one after an install. |
|
|
|
And after uninstalling and re-installing Edge version... Note:
|
|
` Name IsManagementOs VMName SwitchName DockerNAT True DockerNAT PS C:\WINDOWS\system32> Name InterfaceDescription ifIn vEthernet (Internal Ethernet Port Windows Phone Emulator Internal Switch) Hyper-V Virtual Ethernet Adapter #5 25 PS C:\WINDOWS\system32> ifIndex InterfaceAlias AddressFamily NlMtu(Bytes) InterfaceMetric Dhcp ConnectionState PolicyStore 15 Ethernet 2 IPv6 1500 35 Enabled Disconnected ActiveStore PS C:\WINDOWS\system32>`
|
|
From what I can tell after evaluating the output you guys have posted, you are all having problems related to invalid Windows networking configuration. Two things seem to cause DNS resolution problems and Docker error "Timed out while waiting for Docker daemon to be ready", especially while switching to Windows containers mode...
Network traffic will be routed to the network interface having the lowest InterfaceMetric value. If you take a peak at your routing tables, you will notice that route metric and interface metric are summed up and then used to determine routing. Lower values have priority. Although it may appear your routing tables are correct, because IPs are getting routed correctly but DNS is not, the Host Networking Service (HNS) also needs to configure DNS properly, and it uses InterfaceMetric for choosing routes based on priority. HNS is a brand new Windows service that works alongside WinNAT and VFP drivers, dynamically creating port forwarding rules, mapping and policy for those drivers. HNS is also responsible for the creation and management of virtual switches, address translation (NAT), IP addresses, IP pools, DNS, namespaces, endpoints, ports, filter driver policies, etc. for both Hyper-V and Docker. I think that HNS is actually supposed to be able to recognize MediaConnectionState and re-order routes appropriately when an adapter is in the disconnected or disabled state, but currently this functionality does not exist in HNS, therefore it is required that you manually set the order using InterfaceMetric values when there are multiple physical network adapters present. THE SOLUTION: By default, Windows automatically assigns InterfaceMetric values based on LinkSpeed. Gigabit Ethernet adapters are often assigned the lowest value of '5' and 802.11ac Wi-Fi adapters are often assigned a value of '35'. In this example case, if Wi-Fi is your primary internet-connected network adapter, and Ethernet is disconnected or even disabled, your containers and VMs might have direct IP address communication, but no DNS resolution, and it's likely you would get a "Timed out while waiting for Docker daemon to be ready" error when attempting to start Docker or switch to Windows Containers mode. Run the following in an elevated Powershell session to view current configuration: Then assign your primary interface ('Wi-Fi' in this example) to a lower InterfaceMetric than all others: Make sure InterfaceMetric is changed to the same low value for both IPv4 and IPv6. You can also change adapter options in Windows control panel, instead of Powershell, by un-checking "automatic metric" and entering a value in the field. Note: you should not have any NetNats set up manually, as this will break things currently. Remove all NetNats by running the following in an elevated Powershell session: Also, you will want to remove any external switches, bridges or internet connection sharing until everything else is configured and working properly. Reboot until 'Default Switch' and 'nat' are both in the 172.16.0.0/12 range (172.16.0.0 - 172.31.255.255). Sometimes it takes a couple reboots for HNS to get it right. If your system uses a 'vEthernet (HvsiIcs)' network adapter, it may not appear until after you open Microsoft Edge browser in Application Guard mode first. This adapter will most likely be assigned an IP in the 192.168.0.0/16 range (192.168.0.0 - 192.168.255.255). If HNS is struggling to get it right, or if you want to completely remove all dynamic switches and start with a fresh HNS configuration, you can do the following with elevated permissions:
Keep in mind that the HNS service does it's work dynamically and on-the-fly, so if you are browsing network switches in Hyper-V/Docker, or running Get-Net* commands in Powershell, the HNS service will be queried during these actions and may overwrite your settings, and will likely re-start the HNS and/or Docker services. I recommend completing your tasks and rebooting immediately. |
|
Thanks for the suggestions. Default Switch' and 'nat' were already in the correct range. I tried to apply them all, but am not sure what to do about the following. My IT department set up my main Ethernet connection to use "vEthernet (External Switch LAN)". Here is the relevant excerpt from ipconfig: Docker 18.0.6.1-ce still fails to run Windows containers, timing out instead. Linux containers seem to work. Any idea what to do about "vEthernet (External Switch LAN)"? |
|
Also, why can I run version 18.0.3.1 without issue with my existing network setup, but 18.0.6.1 runs only in Linux container mode? |
|
If you need to install an old version so you can get back to work you can download from here https://docs.docker.com/docker-for-windows/release-notes/#docker-community-edition-18060-ce-win72-2018-07-26 Version 18.03.1-ce-win65 (17513) did the trick for me. |
|
I encountered this issue on a long-lived Windows 10 machine. In this case, it was due to one or more conflicting tweaks/hacks/workarounds/etc in the Hyper-V default switch configuration. As the changes were ancient and, thus, long forgotten, I fixed it by cutting my losses and running: |
|
@Monte-Christo There were so many major code changes between 18.03 and 18.06 that it's really hard to guess why 18.03 works in your case. Regarding your 'vEthernet (External Switch LAN)' network adapter. My testing has shown that an External switch that's been bridged to the primary physical adapter, or uses it's gateway via ICS, can be problematic and can cause the issue that you're experiencing. The Host Networking Service (HNS) that Windows 10 uses for Docker is extremely finicky right now in general, and I've found that any network configuration other than the standard "default" style configuration can cause issues and making troubleshooting very difficult. It's easiest to start from a good "baseline". I recommend making note of your current networking configuration and then reset it all back to "default" to get Docker running, and then make your custom changes back to it one by one after it works. That being said, I would completely remove the "External Switch Lan" virtual switch and associated host network adapter. Of coarse, you may want to check with your IT dept. first to make sure that's okay to do. Also, I would recommend upgrading Docker to the current edge branch release v2.0.0.0-beta1-win75, if you can. I've found it to be much more stable, and there are additional code changes in this version that relate to host name resolution. Not sure if it would help you, but when I was running versions 18.06.xx the "experimental" mode always seemed to work better, as did setting the daemon configuration in Advanced mode. Good luck getting things working. If you need anything feel free to reply. I'll be keeping an eye on this issue. |
|
Thanks for the assessment and the suggestions, @xtremeperf. |
|
Unfortunately, Docker for Windows v2.0.0.0-beta1 has the same problem as v18.0.6. Trying to switch to Windows container mode results in a timeout. |
|
Yes, your 'External Switch LAN' most definitely wasn't created by Docker. That would have been set up for the Hyper-V VMs. External switches, when created in the Hyper-V Virtual Switch Manager, get bridged to the host computer's physical network adapter, and therefore any VM setup to use the External Switch will get set up on the host's upstream network as if it were another physical machine in the office. I'm looking back again through the command output you posted, and there is so much that doesn't make since. I'm thinking that there are network configuration issues that have been caused by changes made over a period of time, and it's all conflicting right now. One thing that doesn't make since is the order of the Hyper-V Virtual Ethernet Adapters. They should be numbered in the order in which they were created, and there's no way they should have been created in that order. That external switch needs to be removed to start with. I doubt it's even being used for anything, right? You really need to wipe out the whole network configuration and configure it from scratch using the directions I posted earlier. It's easy enough to set a restore point, or copy down those settings, just in case you want to roll it back to the current config. Also, you need Virtualization Enabled, but you need two specific features installed and active in Windows under "Turn Windows Features On/Off". You can search for that in Windows to take you straight there. "Hyper-V" needs to be activated, and "Containers" needs to be activated. Not the Container Image Manager, though. Also, be sure that BOTH Docker services are running when you switch to Windows Containers mode... the Docker Daemon is called Docker Engine (dockerd.exe) and the Docker Docker to the Named Pipe is called Docker for Windows Service (com.docker.service) |
|
@xtremeperf. OK, I was able to remove the External Switch and some other junk, followed your instructions above about the HNS service, but am still getting the timeout with the newer Docker versions. I also did the vms bit suggested by @nimerix . Here is what i am down to: I am unable o to remove anything else as I can only disable network adapters, the delete option is grayed out. I also checked in device manager, but none of these Loopback or Local Area Connection thingies appears there. How do I get back to a clean slate? |
|
I have this issue too, which is a certain show stopper in using Docker. |
|
@Monte-Christo Your networking is looking pretty good now. You definitely have the InterfaceMetric values configured properly. Something must still be preventing localhost access, and stopping the daemon from accessing the named pipe. I would suggest evaluating the Docker troubleshooting logs after it fails to start, to get your next clue about what's preventing access. As far as a clean slate, you would un-install Docker, and then remove Windows Features that enable Hyper-V and Containers. Then restart Windows a couple times. Then enable Hyper-V and Containers features in Windows. Restart a couple times. Then install Docker. Again, making sure that your InterfaceMetric is ordered appropriately. |
|
After having tested Docker for Windows on a Windows 10 machine, I decided to use this for our CI with Jenkins on a Server 2016 (1607) machine. But we are seeing the exact same issues described here. I've tried all the suggestions but nothing seems to have helped. This is a brand new server with no prior network configuration or Hyper-V configuration - just an out of the box install with Hyper-V and Container features installed. |
I found the cause of the issue in my particular case and raised a new ticket here; #2768 Hopefully this helps others experiencing a similar issue. |
|
@xtremeperf I followed your suggestions for a clean start, but am still getting the timeout with Windows containers. Linux containers work just fine. Downgrading to 18..03 again. When I have some time, I will dig into the logs. This is getting frustrating, the more so as many others are seeing this. |
|
After my latest unsuccessful attempt at getting Docker for Windows 18.0.6 Stable or 2.0.0.0 Beta1 Edge to run Windows containers, I created another diagnostics upload. Diagnostic ID: 3EA8E0C9-3981-4E36-BB55-5A0D609553CC/20181025132736 In the logs there are about 25000 separate entries just like this one: My Windows event log is full of these errors, all occurring multiple times: What do I do? |
|
Same issue - diagnostic id: 39386141-1BB1-4FB7-ADB7-F1652D21D3F0/20181116111139 |
|
Hey @Monte-Christo … It looks like you have an issue going on with permissions. Have you tried as admin? |
|
Issues go stale after 90d of inactivity. Prevent issues from auto-closing with an If this issue is safe to close now please do so. Send feedback to Docker Community Slack channels #docker-for-mac or #docker-for-windows. |
|
Same issue here! I'm using Docker v2.1.0.2. When I try to start Docker, i got this error window: A crash report was uploaded with diagnostic ID: |
|
meet the same problem... |
|
Closed issues are locked after 30 days of inactivity. If you have found a problem that seems similar to this, please open a new issue. Send feedback to Docker Community Slack channels #docker-for-mac or #docker-for-windows. |
and others
Expected behavior
Get started with Docker, and pull 'hello-world image' nornally.
Actual behavior
Timed out while waiting for Docker daemon to be ready
於 Docker.Backend.Processes.WindowsDockerDaemon.WaitForDaemonToBeReady() 於 C:\gopath\src\github.com\docker\pinata\win\src\Docker.Backend\Processes\WindowsDockerDaemon.cs: 行 147
於 Docker.Backend.ContainerEngine.Windows.DoStart(Settings settings, String daemonOptions) 於 C:\gopath\src\github.com\docker\pinata\win\src\Docker.Backend\ContainerEngine\Windows.cs: 行 222
於 Docker.Backend.ContainerEngine.Windows.Restart(Settings settings, String daemonOptions) 於 C:\gopath\src\github.com\docker\pinata\win\src\Docker.Backend\ContainerEngine\Windows.cs: 行 153
於 Docker.Core.Pipe.NamedPipeServer.<>c__DisplayClass9_0.b__0(Object[] parameters) 於 C:\gopath\src\github.com\docker\pinata\win\src\Docker.Core\pipe\NamedPipeServer.cs: 行 48
於 Docker.Core.Pipe.NamedPipeServer.RunAction(String action, Object[] parameters) 於 C:\gopath\src\github.com\docker\pinata\win\src\Docker.Core\pipe\NamedPipeServer.cs: 行 180
Information
Steps to reproduce the behavior
The text was updated successfully, but these errors were encountered: