v4.16.2: `docker context list` gets "unexpected end of JSON input"

[rfay]

• I have tried with the latest version of Docker Desktop
• I have tried disabling enabled experimental features
• I have uploaded Diagnostics
• Diagnostics ID: EE17CD29-04CD-4EEB-A128-5EE34779FFD8/20230119214601

Actual behavior

PS C:\Users\testbot> docker context list
unexpected end of JSON input

Expected behavior

docker context list should give a list of docker contexts

This happens in PS and in WSL2 as well, same thing. I tested on two different Windows systems.
I tested on macOS and did not see this.

Information

• Windows Version: 11
• Docker Desktop Version: 4.16.1
• WSL2 or Hyper-V backend? WSL2
• Are you running inside a virtualized Windows e.g. on a cloud server or a VM: No

Output of & "C:\Program Files\Docker\Docker\resources\com.docker.diagnose.exe" check

Skipped since I haven't ever seen it work

Steps to reproduce the behavior

On 4.16.1, docker context list

[rfay]

I should note that as a result of this I have to roll back to 4.15.0 on test runners. But that is no longer allowed by the installer, which says "Oh, it's up-to-date", meaning that I'll have to uninstall and reinstall to get to 4.15.0.

[rfay]

docker context use default works.
docker context inspect default works.

[rfay]

And reverting to v4.15.0 I still have this problem, so I imagine it's some file left as-is during uninstall? Tried removing .docker/config.json but that didn't help.

[rfay]

I did find a 4.16.1 (that was updated from a previous version) that does not show this behavior. These two that are failing are fresh installs.

[rfay]

Now this is happening on a 3rd machine running 4.16.1, and I have no solutions.

[nicks]

Under the hood, I think 'docker context ls' reads json files on disk, decodes them, and pretty prints them. It doesn't change much. I doubt it changed between 4.15 and 4.16. I think the files are under ~/.docker/contexts or something similar? Probably they're getting corrupted somehow by some command that runs before.

Maybe there's a docker/cli bug here to print the file where the error is coming from.

[rfay]

Thanks @nicks -

Here's what I saw:

$ ls -l .docker/contexts/meta/*/*
-rwxrwxrwx 1 buildkite-agent buildkite-agent 0 Jan 19 16:31 .docker/contexts/meta/fe9c6bd7a66301f49ca9b6a70b217107cd1284598bfc254700c989b916da791e/meta.json

On each system there was a meta.json that was empty. Deleting them made docker context ls work.

On each of two Windows/WSL2 systems I examined, the contexts were zeroed out/corrupted, and this was true both inside wsl2 in ~/.docker/contexts and also on PowerShell in ~/.docker/contexts.

I imagine something in 4.16.1 is zeroing them out, not sure.

[rfay]

This problem continues in 4.16.2 without change. I find that if I remove the ~/.docker/contexts it gets recreated with an empty value when Docker Desktop is restarted.

[nicks]

possibly related - #12561 (though the exact symptoms are slightly different)

[rfay]

Thanks - these context files seem to be empty, so I think although the symptom is the same, the cause may be different.

[fari-99]

so i got this problem too, using Docker Desktop for Windows version 4.16.2 (95914).

the only fix i can do is using docker/desktop-linux#57 (comment) solution.

1. vim ~/.docker/context/meta/{some hash}/meta.json
2. put this in the meta.json
   { "Name": "default", "Metadata": { "StackOrchestrator": "swarm" }, "Endpoints": { "docker": { "Host": "unix:///var/run/docker.sock", "SkipTLSVerify": false } }, "TLSMaterial": {} }
3. do docker context ls again.

unfortunately, when i restart my docker desktop, the context got cleared again. and i need to do this all over again.
just a workaround, not a true solution.

[nicks]

Clarification question @rfay : after you delete the directory, how long does it take to re-occur? On every desktop restart? After a few hours? Intermittently?

[KarelVendla]

I am also facing this problem.

I've created a dummy context.
example:
docker context create wsl-default
And then deleted the broken one.

I get the issue less often, but it still occurs. Before I would just delete the hash folder with the empty meta.json, then the problem would come back a lot quicker (I recon docker doesn't like when your meta folder is empty).

It seems to occur when I crash my docker, it sometimes happens when I've restarted my PC. Haven't really noticed a distinct pattern yet.

The hash with the empty meta.json always seems to have the same hash, maybe that might give some clues.