lima docker info fails yet works

[ghost]

$ colima start
INFO[0000] starting colima
INFO[0000] runtime: docker
INFO[0000] starting ...                                  context=vm
INFO[0092] provisioning ...                              context=docker
INFO[0093] starting ...                                  context=docker
FATA[0175] error starting docker: error running [lima sudo docker info], output: "errors pretty printing info", err: "exit status 1"

$ LIMA_INSTANCE=colima lima sudo docker info
Client:
 Context:    default
 Debug Mode: false

Server:
 Containers: 0
  Running: 0
  Paused: 0
  Stopped: 0
 Images: 0
 Server Version: 20.10.18
 Storage Driver: overlay2
  Backing Filesystem: extfs
  Supports d_type: true
  Native Overlay Diff: true
  userxattr: false
 Logging Driver: json-file
 Cgroup Driver: cgroupfs
 Cgroup Version: 1
 Plugins:
  Volume: local
  Network: bridge host ipvlan macvlan null overlay
  Log: awslogs fluentd gcplogs gelf journald json-file local logentries splunk syslog
 Swarm: inactive
 Runtimes: runc io.containerd.runc.v2 io.containerd.runtime.v1.linux
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: 9cd3357b7fd7218e4aec3eae239db1f68a5a6ec6
 runc version: 5fd4c4d144137e991c4acebb2146ab1483a97925
 init version:
 Security Options:
  seccomp
   Profile: default
 Kernel Version: 5.15.68-0-virt
 Operating System: Alpine Linux v3.16
 OSType: linux
 Architecture: x86_64
 CPUs: 1
 Total Memory: 1.939GiB
 Name: colima
 ID: LK5P:ASUY:DSO7:GPR5:F7B4:KEBU:SN3Q:V6XQ:OU5E:I27H:5QPM:YIIM
 Docker Root Dir: /var/lib/docker
 Debug Mode: false
 Registry: https://index.docker.io/v1/
 Labels:
 Experimental: false
 Insecure Registries:
  127.0.0.0/8
 Live Restore Enabled: false

$

• Colima 0.4.6
• Lima 0.12.0, same with 0.11.3
• Qemu 7.1.0
• Debian 11.5

Help?

Additional verbose logs:

time="2022-10-20T08:49:38-04:00" level=trace msg="cmd [\"lima\" \"sudo\" \"service\" \"docker\" \"start\"]"
 * /var/log/docker.log: creating file
 * /var/log/docker.log: correcting owner
 * Starting Docker Daemon ... [ ok ]
time="2022-10-20T08:49:39-04:00" level=trace msg="cmd [\"lima\" \"sudo\" \"docker\" \"info\"]"
time="2022-10-20T08:49:46-04:00" level=trace msg="cmd [\"lima\" \"sudo\" \"docker\" \"info\"]"
time="2022-10-20T08:49:53-04:00" level=trace msg="cmd [\"lima\" \"sudo\" \"docker\" \"info\"]"
time="2022-10-20T08:49:59-04:00" level=trace msg="cmd [\"lima\" \"sudo\" \"docker\" \"info\"]"
time="2022-10-20T08:50:06-04:00" level=trace msg="cmd [\"lima\" \"sudo\" \"docker\" \"info\"]"
time="2022-10-20T08:50:13-04:00" level=trace msg="cmd [\"lima\" \"sudo\" \"docker\" \"info\"]"
time="2022-10-20T08:50:19-04:00" level=trace msg="cmd [\"lima\" \"sudo\" \"docker\" \"info\"]"
time="2022-10-20T08:50:26-04:00" level=trace msg="cmd [\"lima\" \"sudo\" \"docker\" \"info\"]"
time="2022-10-20T08:50:32-04:00" level=trace msg="cmd [\"lima\" \"sudo\" \"docker\" \"info\"]"
time="2022-10-20T08:50:39-04:00" level=trace msg="cmd [\"lima\" \"sudo\" \"docker\" \"info\"]"
time="2022-10-20T08:50:46-04:00" level=trace msg="cmd [\"lima\" \"sudo\" \"docker\" \"info\"]"
time="2022-10-20T08:50:52-04:00" level=trace msg="cmd [\"lima\" \"sudo\" \"docker\" \"info\"]"
time="2022-10-20T08:50:59-04:00" level=trace msg="cmd [\"lima\" \"sudo\" \"docker\" \"info\"]"
time="2022-10-20T08:51:00-04:00" level=fatal msg="error starting docker: error running [lima sudo docker info], output: \"errors pretty printing info\", err: \"exit status 1\""

[ghost]

Can confirm it was a timing problem. After increasing the timeout in docker.go it all worked out.

[abiosoft]

Are you emulating x86_64 on an M1 device? Ideally it should not be so slow to exceed the timeout.

[ghost]

It was on Intel. But yeah, with time-based logic things can be flaky depending on the various bottlenecks - maybe a project is building, or an antivirus is taking up all hardware resources, or something else. May I suggest, on timeout errors, to let the user in stdout/err know that it was a timeout error? CLI-configurable timeouts would be even better, but I think helpful error handling is more important.

I'm sorry I can't submit a PR for this, not a Go dev myself.