Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bollard failing to parse docker system df JSON #78

Closed
mac-chaffee opened this issue Jul 27, 2020 · 8 comments
Closed

Bollard failing to parse docker system df JSON #78

mac-chaffee opened this issue Jul 27, 2020 · 8 comments
Labels
bug Something isn't working

Comments

@mac-chaffee
Copy link
Contributor

mac-chaffee commented Jul 27, 2020

Description
I'm getting this error when running docuum from source:

[2020-07-26 23:24:54 -04:00 ERROR] Unable to determine the disk space used by Docker images: Error { inner:

Failed to deserialize JSON: invalid type: string "2020-06-17T14:55:03.4970949Z", expected i64 at line 1 column 76799 }.

It's errorring on this bit of JSON (obtained by running curl --unix-socket /var/run/docker.sock http:/v1.40/system/df | jq | less)

{
      "ID": "rrc3gr2ks5mm41ntmlqsqu2k4",
      "Parent": "2tub3atjmssqqh0ji08jjc5oj",
      "Type": "regular",
      "Description": "fileop target",
      "InUse": false,
      "Shared": false,
      "Size": 353,
      "CreatedAt": "2020-06-17T14:55:03.5952988Z",
      "LastUsedAt": "2020-06-17T14:55:44.6490503Z",
      "UsageCount": 1
    }

I worry this might be a bollard bug where it doesn't expect some docker objects to still be reporting dates in iso8601 format.

Instructions to reproduce the bug
Ensure matching versions of docker, OS, docuum. Then:

git checkout v0.10.0
cargo run -- --threshold=50GB

System information:

  • OS: macOS Catalina 10.15.6
  • Docker version:
$ docker version
Client: Docker Engine - Community
 Version:           19.03.8
 API version:       1.40
 Go version:        go1.12.17
 Git commit:        afacb8b
 Built:             Wed Mar 11 01:21:11 2020
 OS/Arch:           darwin/amd64
 Experimental:      false

Server: Docker Engine - Community
 Engine:
  Version:          19.03.8
  API version:      1.40 (minimum version 1.12)
  Go version:       go1.12.17
  Git commit:       afacb8b
  Built:            Wed Mar 11 01:29:16 2020
  OS/Arch:          linux/amd64
  Experimental:     false
 containerd:
  Version:          v1.2.13
  GitCommit:        7ad184331fa3e55e52b890ea95e65ba581ae3429
 runc:
  Version:          1.0.0-rc10
  GitCommit:        dc9208a3303feef5b3839f4323d9beb36df0a9dd
 docker-init:
  Version:          0.18.0
  GitCommit:        fec3683
  • Docuum version: 0.10.0

Additional context

Looks like starting bollard with Docker::connect_with_local_defaults() means it will try to use API version 1.40: https://docs.rs/bollard/0.7.1/src/bollard/docker.rs.html#72-75

Maybe we could experiment with an older API version. Or maybe docker just doesn't properly display old entries and I just need to do a docker system prune. Or we may just need to send this bug report to the bollard devs.

@stepchowfun
Copy link
Owner

Shoot. I was afraid something like this would happen with Bollard. I'll revert that PR tonight. Would you mind filing this bug with Bollard? If they fix it on their end, we can bring it back.

@stepchowfun
Copy link
Owner

Thank you for reporting this BTW!

The weird thing is... "it works on my machine"

@mac-chaffee
Copy link
Contributor Author

Just adding a bit more info: think the blame rests on Docker itself, because their API docs seem to be literally lying lol: https://docs.docker.com/engine/api/v1.40/#operation/SystemDataUsage

^ that claims BuildCache objects use Integers for their CreatedAt dates

stepchowfun added a commit that referenced this issue Jul 27, 2020
This reverts commit 5cdbda4, reversing
changes made to b246d63.

See #78.
@stepchowfun
Copy link
Owner

Interesting. The weird thing is that on my machine I actually get an int64. I have the same version of Docker (19.03.8).

@mdonoughe
Copy link

That's very interesting. I looked at the code and it looks like it always uses the default handling of outputing an RFC 3339 string.

@stepchowfun
Copy link
Owner

Thanks @mdonoughe for reporting the issue upstream!

@mac-chaffee
Copy link
Contributor Author

Thanks for handling this @stepchowfun @mdonoughe !

Looks like the inability to reproduce is due to my use of BuildKit. I should have known that would come back to bite me one day haha!

@stepchowfun
Copy link
Owner

I'm quite glad you had BuildKit enabled and discovered this! We should test with BuildKit both enabled and disabled as part of our release process.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

3 participants