Repository navigation
Bad exit status for docker system info on failure #5900
Copy link
Copy link
Closed
Labels
Description
Description
docker system info returns 0 (success) even on failures.
Reproduce
$ DOCKER_HOST=unix:///non-existent docker system info --format '{{.Architecture}}' ; echo $?
Cannot connect to the Docker daemon at unix:///non-existent. Is the docker daemon running?
0Expected behavior
on failures, any exit value other than 0 would be appropriate.
docker version
Client: Docker Engine - Community
Version: 28.0.1
API version: 1.48
Go version: go1.23.6
Git commit: 068a01e
Built: Wed Feb 26 10:41:12 2025
OS/Arch: linux/amd64
Context: default
Server: Docker Engine - Community
Engine:
Version: 28.0.1
API version: 1.48 (minimum version 1.24)
Go version: go1.23.6
Git commit: bbd0a17
Built: Wed Feb 26 10:41:12 2025
OS/Arch: linux/amd64
Experimental: false
containerd:
Version: 1.7.25
GitCommit: bcc810d6b9066471b0b6fa75f557a15a1cbf31bb
runc:
Version: 1.2.4
GitCommit: v1.2.4-0-g6c52b3f
docker-init:
Version: 0.19.0
GitCommit: de40ad0docker info
Client: Docker Engine - Community
Version: 28.0.1
Context: default
Debug Mode: false
Plugins:
buildx: Docker Buildx (Docker Inc.)
Version: v0.21.1
Path: /usr/libexec/docker/cli-plugins/docker-buildx
compose: Docker Compose (Docker Inc.)
Version: v2.33.1
Path: /usr/libexec/docker/cli-plugins/docker-compose
Server:
Containers: 1
Running: 1
Paused: 0
Stopped: 0
Images: 29
Server Version: 28.0.1
Storage Driver: overlay2
Backing Filesystem: extfs
Supports d_type: true
Using metacopy: false
Native Overlay Diff: true
userxattr: false
Logging Driver: json-file
Cgroup Driver: systemd
Cgroup Version: 2
Plugins:
Volume: local
Network: bridge host ipvlan macvlan null overlay
Log: awslogs fluentd gcplogs gelf journald json-file local splunk syslog
Swarm: inactive
Runtimes: io.containerd.runc.v2 runc
Default Runtime: runc
Init Binary: docker-init
containerd version: bcc810d6b9066471b0b6fa75f557a15a1cbf31bb
runc version: v1.2.4-0-g6c52b3f
init version: de40ad0
Security Options:
apparmor
seccomp
Profile: builtin
cgroupns
Kernel Version: 6.8.0-55-generic
Operating System: KDE neon 6.3
OSType: linux
Architecture: x86_64
CPUs: 16
Total Memory: 30.66GiB
Name: framework
ID: ed7176be-9632-4d36-b469-32b4cbaab421
Docker Root Dir: /var/lib/docker
Debug Mode: false
Experimental: false
Insecure Registries:
::1/128
127.0.0.0/8
Live Restore Enabled: falseAdditional Info
I'm attempting to use this to manage a dev container, and define the architecture, but when it fails... it is hard to know, and unexpected behaviour happens down the line.
Reactions are currently unavailable
Activity
thaJeztah commentedon Mar 6, 2025
Thanks for reporting; this looks be related to the
--formattemplate used; running the same command, but without a format set does return a non-zero exit code;I know there's some code in this area that tries to parse the template to detect whether a daemon connection is required (so that client-side
infocould still be printed, even with the daemon down). It wouldn't surprise me if something in that area of the code is swallowing the exit code 🤔thaJeztah commentedon Mar 6, 2025
If you only need the architecture (and/or OS), I would recommend using
docker version; it's a much more lightweight endpoint (docker infodoes a lot behind the scenes to collect info, including traversing directories to collect version information for CLI plugins);The architecture returned there is using the formats used by Golang's GOOS, which also matches the format used for platform strings in OCI images.
Comparison in time taken for both;
Benehiko commentedon Mar 10, 2025
I see what the issue is here, the
infocommand prints the error itself and does not propagate the error up the stack to the main function. I'll see if I can do a quick fix for this.https://github.com/docker/cli/blob/master/cli/command/system/info.go#L113
thaJeztah commentedon Mar 10, 2025
Ah! Yes, looks indeed in one of the areas I had in mind. It's a bit gnarly for sure; I think it was in an attempt to make the
infodo as much as possible, even if there's some failure (as the information needed may be client-only). I guess we need to store the error and if no other error is returned, return it (and/or anerrors.Joinfor multiple errors 🤔)