Timed out waiting for the lifecycle-server to start.

[thnk2wn]

• [ X ] I have tried with the latest version of my channel (Stable or Edge)
• [ X ] I have uploaded Diagnostics
• Diagnostics ID: E5488066-8079-4EC3-AF15-90B9D424A9B0/20191106132753

Expected behavior

Docker starts up after previous shutdown.

Actual behavior

Docker times out after 600 seconds on startup. Related issue #5081.

Timed out waiting for the lifecycle-server to start.
This may be the result of a slow environment or there may be a real problem.
This timeout can be increased by editing settings.json, value 'lifecycleTimeoutSeconds'.
This file is usually in C:\Users\(your username)\AppData\Roaming\Docker

   at Docker.Backend.LifecycleClient.WaitForServerUp(TimeSpan timeout)
   at Docker.Backend.ContainerEngine.WslEngine.DoStart(Settings settings, String daemonOptions, Credential credential)
   at Docker.Backend.ContainerEngine.WslEngine.Start(Settings settings, String daemonOptions, Credential credential, Boolean retry)
   at Docker.Backend.ContainerEngine.WslEngine.Start(Settings settings, String daemonOptions, Credential credential, Boolean retry)
   at Docker.Backend.ContainerEngine.WslEngine.Start(Settings settings, String daemonOptions, Credential credential)
   at Docker.Backend.BackendNamedPipeServer.b__8_2(Object[] args)
   at Docker.Core.Pipe.NamedPipeServer.<>c__DisplayClass9_0.b__0(Object[] parameters)
   at Docker.Core.Pipe.NamedPipeServer.RunAction(String action, Object[] parameters)

Information

• Windows Version: 10.0.19013.1
• Docker Desktop Version: 2.1.5.0 (40323)
• Are you running inside a virtualized Windows e.g. on a cloud server or on a mac VM: No Windows machine
• Using WSL 2: Yes

Steps to reproduce the behavior

This was working originally, not sure what triggered it.

1. Installed prereqs for WSL2 on Windows and latest Docker
2. Everything worked originally
3. Built and pushed some containers
4. Rebooted Windows
5. Docker fails on startup and restart

[thnk2wn]

Possible duplicate of #5069

[simonferquel]

I'll have a look at it tomorrow, thanks for the diag report!

[simonferquel]

Simple question: is it consistently failing or does the problem appear randomly ?
Does restarting windows solve the issue ?

[thnk2wn]

@simonferquel Random. Initially it seemed like a reboot caused the issue. After a fresh startup of Windows I noticed it was no longer working. Then I tried restarting Docker multiple times but kept getting errors. Another reboot fixed it. I think I restarted before leaving work so my machine was idle for maybe 15 hours. Maybe the idle time came into play or some other change I’m not aware of.

[simonferquel]

I yet have to find the root issue for this one. Maybe the idle time comes to play, you are right (did the machine went to sleep / hybernation while idle?)
In the mean time I have a workaround for avoiding to reboot for you:

• in task manager: kill "docker desktop.exe"
• in service manager: restart "docker desktop service"
• from a command prompt run "wsl --shutdown"
• run docker desktop again
  This way it will only restart wsl utility VM and put docker desktop in a clean state without rebooting.

[thnk2wn]

@simonferquel I'm sure the machine went to sleep as it's set to after an hour or so. I see Event Log entries from Docker Service indicating it handled the power events both sleep and wake ("PowerEvent handled successfully by the service.").

Not sure that it's helpful but there are also these in the event log around the time it happened.

Application: Docker Desktop.exe
Framework Version: v4.0.30319
Description: The process was terminated due to an unhandled exception.
Exception Info: System.InvalidOperationException
   at System.Windows.Forms.Control.MarshaledInvoke(System.Windows.Forms.Control, System.Delegate, System.Object[], Boolean)
   at System.Windows.Forms.Control.BeginInvoke(System.Delegate, System.Object[])
   at System.Windows.Forms.WindowsFormsSynchronizationContext.Post(System.Threading.SendOrPostCallback, System.Object)
   at System.Threading.Tasks.AwaitTaskContinuation.RunCallback(System.Threading.ContextCallback, System.Object, System.Threading.Tasks.Task ByRef)
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at System.Threading.ExecutionContext.RunInternal(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)
   at System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)
   at System.Threading.QueueUserWorkItemCallback.System.Threading.IThreadPoolWorkItem.ExecuteWorkItem()
   at System.Threading.ThreadPoolWorkQueue.Dispatch()

Faulting application name: Docker Desktop.exe, version: 2.1.5.40323, time stamp: 0xed6456e9
Faulting module name: KERNELBASE.dll, version: 10.0.19013.1, time stamp: 0x6d1c8fa4
Exception code: 0xe0434352
Fault offset: 0x000000000003b4a9
Faulting process id: 0x41e4
Faulting application start time: 0x01d594a12adecc41
Faulting application path: C:\Program Files\Docker\Docker\Docker Desktop.exe
Faulting module path: C:\WINDOWS\System32\KERNELBASE.dll
Report Id: 37c0e0d2-164f-4280-ba42-e03cf29cc5ed
Faulting package full name: 
Faulting package-relative application ID: 

Thanks for the workaround. Maybe I'll create a script for it. Including one in the distribution would be nice too.

[thnk2wn]

@simonferquel Created related issue #5093. That's actually the initial error I saw. This issue on timing out was after restarting Docker to try to recover from that issue.

[jmb12686]

I yet have to find the root issue for this one. Maybe the idle time comes to play, you are right (did the machine went to sleep / hybernation while idle?)
In the mean time I have a workaround for avoiding to reboot for you:

• in task manager: kill "docker desktop.exe"
• in service manager: restart "docker desktop service"
• from a command prompt run "wsl --shutdown"
• run docker desktop again
  This way it will only restart wsl utility VM and put docker desktop in a clean state without rebooting.

For what it's worth, these steps did work for me (to an extent). These steps allowed me to get past any Docker Desktop startup errors. In powershell I'm able to connect to docker daemon, presumably using the Hyper-V Docker Desktop VM. However, even after disabling / re-enabling WSL 2 based engine in the Docker Desktop settings, WSL is unable to connect to daemon.

[thnk2wn]

In case it's helpful to anyone, a little PS script for this.

# Run elevated
Get-Process "Docker Desktop" | Stop-Process
Restart-Service "Docker Desktop Service"
wsl --shutdown
Invoke-Item "$($env:PROGRAMFILES)\Docker\Docker\Docker Desktop.exe"

[simonferquel]

2.1.6.0 should fix the issue

[rfay]

With Docker Desktop 2.1.6.0, I have

• WSL2 enabled (docker working fine from within enabled container)
• docker context set to "wsl"

If I run docker ps I get:
error during connect: Get http://%2F%2F.%2Fpipe%2Fdocker_wsl/v1.40/containers/json: open //./pipe/docker_wsl: The system cannot find the file specified.

[simonferquel]

Wsl context should not be used anymore. It is an artifact created by the old tech preview. You can safely remove it.

[scythx]

I encounter the same issue in version/2.1.7.0. Any workaround on this beside reset factory?

Here's what i got from docker log.

[06:23:06.029][WslEngine         ][Info   ] Starting Linuxkit distro
[06:23:06.029][WslEngine         ][Info   ] Waiting for lifecycle server...
[06:23:06.029][LifecycleClient   ][Info   ] Waiting for lifecycle-server for up to 00:10:00
[06:23:06.029][APIRequestLogger  ][Info   ] [bea89191] <LifecycleClient start> GET http://localhost/ping
[06:23:06.292][ApiProxy          ][Info   ] time="2020-01-19T06:23:06+07:00" msg="🍀 socket server listening : \\\\.\\pipe\\dockerGuiToDriver"
[06:23:06.317][ApiProxy          ][Info   ] time="2020-01-19T06:23:06+07:00" msg="🍀 socket server starting : \\\\.\\pipe\\dockerGuiToDriver"
[06:23:06.317][ApiProxy          ][Info   ] time="2020-01-19T06:23:06+07:00" level=info msg=waitForDockerUp
[06:23:06.318][ApiProxy          ][Info   ] time="2020-01-19T06:23:06+07:00" msg="Static DNS lookup table: map[docker-desktop.:192.168.65.3 docker-for-desktop.:192.168.65.3 docker.for.win.gateway.internal.:192.168.65.1 docker.for.win.host.internal.:192.168.65.2 docker.for.win.http.internal.:192.168.65.1 docker.for.win.localhost.:192.168.65.2 gateway.docker.internal.:192.168.65.1 host.docker.internal.:192.168.65.2 kubernetes.docker.internal.:192.168.65.3 vm.docker.internal.:192.168.65.3]"
[06:23:06.321][ApiProxy          ][Info   ] time="2020-01-19T06:23:06+07:00" msg="Writing C:\\Users\\MyUsername\\AppData\\Roaming\\Docker\\gateway_forwards.json"
[06:23:10.931][VpnKit            ][Info   ] vpnkit.exe: Gateway forwards file C:\Users\MyUsername\AppData\Roaming\Docker\gateway_forwards.json has changed
[06:23:10.931][VpnKit            ][Info   ] vpnkit.exe: Reading gateway forwards file from C:\Users\MyUsername\AppData\Roaming\Docker\gateway_forwards.json
[06:23:10.931][VpnKit            ][Info   ] vpnkit.exe: New Gateway forward configuration: [{"protocol":"udp","external_port":53,"internal_ip":"127.0.0.1","internal_port":60325},{"protocol":"tcp","external_port":53,"internal_ip":"127.0.0.1","internal_port":52345}]
[06:23:14.487][WslEngine         ][Info   ] T h e   r e m o t e   p r o c e d u r e   c a l l   f a i l e d . 
 
 
[06:23:14.487][VpnKitBridge      ][Info   ] Error: not a connection to a mulitplexer; received bad magic string 'T h e   r e m o t e   p r o c e d u r e   c a l l   '
[06:23:14.503][VpnKitBridge      ][Fatal  ] time="2020-01-19T06:23:14+07:00" msg="not a connection to a mulitplexer; received bad magic string 'T\x00h\x00e\x00 \x00r\x00e\x00m\x00o\x00t\x00e\x00 \x00p\x00r\x00o\x00c\x00e\x00d\x00u\x00r\x00e\x00 \x00c\x00a\x00l\x00l\x00 \x00'"
[06:23:14.503][WslEngine         ][Warning] distro stopped
[06:23:14.509][VpnKitBridge      ][Error  ] Process died

[simonferquel]

@raefaldhia the issue you have is the same as microsoft/WSL#4726. It will soon be fixed by Microsoft. In the mean time a simple restart should fix the issue.

[docker-robott]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale comment.
Stale issues will be closed after an additional 30d of inactivity.

Prevent issues from auto-closing with an /lifecycle frozen comment.

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.
/lifecycle stale

[docker-robott]

Closed issues are locked after 30 days of inactivity.
This helps our team focus on active issues.

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.
/lifecycle locked