Running diagnostics stays stuck on "Diagnosing..." screen

[jpetazzo]

Expected behavior

I run "diagnose and feedback" from the menu.

I expect to know what's going on.

(In that specific case: I tried to reset D4M to factory defaults to scrap some disk space, and it failed telling me "there was a problem.")

Actual behavior

The diagnostic screen opens. Then in the black rectangle it just says "Diagnosing..." but stays there forever (waited 10 minutes).

Information

This was just after trying to reset D4M to factory defaults. After that, my D4M install seems to be broken (will open separate issue about that).

Steps to reproduce the behavior

Can't reproduce: now the diagnostics screen tell me something else.

Suggestions

• display what's going on in real time
• or give instructions about what to do if things time out (I got a magic command a while ago to run the diagnostics from the console but can't find it anymore)
• detect when diagnostics take too long?

[avsm]

Thank you for the bug report. I've filed an internal issue to improve the usability of the Diagnose menu. In the meanwhile, to help diagnose bugs when the GUI is not operational you can also use the Terminal from the CLI:

$ /Applications/Docker.app/Contents/Resources/bin/docker-diagnose -u
<...>
Your unique id is: <...>
Please quote this in all correspondence.

The UUID needs to be pasted into the GitHub issue manually in this case.

[xicubed]

Same issue even from command line hangs after [OK] kern.hv_support.

$ /Applications/Docker.app/Contents/Resources/bin/docker-diagnose -u
macOS: version 10.12.4 (build: 16E195)
Docker.app: version: 17.04.0-ce-mac7 (b598153e2)
Local time: Thu Apr  6 17:19:51 MDT 2017
UTC:        Thu Apr  6 23:19:51 UTC 2017
Timestamp:  20170406-171951
Running diagnostic tests:
[OK]      docker-cli
[OK]      Moby booted
[OK]      driver.amd64-linux
[OK]      vmnetd
[OK]      osxfs
[OK]      db
[OK]      vpnkit
[OK]      disk
[OK]      menubar
[OK]      environment
[OK]      Docker
[OK]      VT-x
[OK]      kern.hv_support

[mapio]

Same as above…

[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

[mapio]

/remove-lifecycle stale

[mapio]

Now proceeds to Hypervisor and finally ends.

$ /Applications/Docker.app/Contents/Resources/bin/docker-diagnose -u
macOS: version 10.12.6 (build: 16G1314)
Docker.app: version: 18.04.0-ce-rc2-mac61 (7e2bb492d35dc35ec0037d8024b7e7be57fc72a9)
Local time: Mon Apr 16 17:21:54 CEST 2018
UTC:        Mon Apr 16 15:21:54 UTC 2018
Timestamp:  20180416-172154
Running diagnostic tests:
[OK]      Files
[OK]      Docker CLI
[OK]      /Users/santini/Library/Containers/com.docker.docker/Data/vms/0/console-ring exists
[OK]      driver.amd64-linux
[OK]      vmnetd
[OK]      osxfs
[OK]      VPNKit
[OK]      Disk
[OK]      Kubernetes
[OK]      environment
[OK]      Docker
[OK]      VT-x
[OK]      kern.hv_support
[OK]      Hypervisor
Docker logs are being collected into /tmp/6981C162-99EC-485D-87C0-7EFED32D5297/20180416-172154.tar.gz
Your unique id is: [EDITED]
Please quote this in all correspondence.

In my case it can be considered close.

[akimd]

Thanks.

[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