docker pull is now interactive #50204
Description
Description
On Fedora 42, we recently got updated from Docker 27.5.1 to 28.2.2 (The same behavior is seen with Docker upstream or Fedora downstream builds.) Since then, scripts that use docker pull to check if the user is able to pull an image (i.e., auth is setup correctly) fail, because docker pull now drops into an interactive mode.
Reproduce
For example, we have a function like the following in a batch script:
function check_docker_pull {
print_log "Attempting to pull $IMAGE_NAME"
docker pull -q "$IMAGE_NAME" >>"$LOG_FILE" 2>&1
return $?
}
With Docker 27.5.1, we got a non-zero return code if the registry could not be accessed and everything was good. Now with Docker 28.2.2, we get this:
$ docker pull icr.io/my-ns/my-image:latest
Login prior to pull:
Log in with your Docker ID or email address to push and pull images from Docker Hub. If you don't have a Docker ID, head over to https://hub.docker.com/ to create one.
You can log in with your password or a Personal Access Token (PAT). Using a limited-scope PAT grants better security and is required for organizations using SSO. Learn more at https://docs.docker.com/go/access-tokens/
Username (iamrefresh):
There are a number of things wrong here:
- We're not pulling from Docker Hub, so the help message does not help the user.
- The registry does not support username/password auth anyways, so the user cannot really enter a username here and get things to work.
- And most importantly: a previously non-interactive command requires now user interaction and hence hangs the script.
We are currently working around the issue with echo "" | docker pull icr.io/my-ns/my-image:latest, but that's really an ugly hack.
Expected behavior
I tried to find the exact commit where this behavior got introduced but couldn't pinpoint a specific one. So I'm not quite sure what the intended behavior here is. But at least: may I request a "--non-interactive" flag/environment variable to docker pull, or alternatively, is there a better way to check for the ability to pull an image? docker manifest inspect could fit the bill, but it's marked experimental.
docker version
Client:
Version: 28.2.2
API version: 1.50
Go version: go1.24.3
Git commit: 1.fc42
Built: Fri May 30 00:00:00 2025
OS/Arch: linux/amd64
Context: default
Server:
Engine:
Version: 28.2.2
API version: 1.50 (minimum version 1.24)
Go version: go1.24.3
Git commit: 1.fc42
Built: Fri May 30 00:00:00 2025
OS/Arch: linux/amd64
Experimental: false
containerd:
Version: 1.7.27
GitCommit: 05044ec0a9a75232cad458027ca83437aae3f4da
runc:
Version: 1.2.5
GitCommit: v1.2.5-0-g59923ef
tini-static:
Version: 0.19.0
GitCommit:docker info
Client:
Version: 28.2.2
Context: default
Debug Mode: false
Plugins:
buildx: Docker Buildx (Docker Inc.)
Version: 0.24.0
Path: /usr/libexec/docker/cli-plugins/docker-buildx
Server:
Containers: 13
Running: 3
Paused: 0
Stopped: 10
Images: 66
Server Version: 28.2.2
Storage Driver: overlay2
Backing Filesystem: btrfs
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
CDI spec directories:
/etc/cdi
/var/run/cdi
Swarm: inactive
Runtimes: runc io.containerd.runc.v2
Default Runtime: runc
Init Binary: /usr/bin/tini-static
containerd version: 05044ec0a9a75232cad458027ca83437aae3f4da
runc version: v1.2.5-0-g59923ef
init version:
Security Options:
seccomp
Profile: builtin
selinux
cgroupns
Kernel Version: 6.14.9-300.fc42.x86_64
Operating System: Fedora Linux 42 (Workstation Edition)
OSType: linux
Architecture: x86_64
CPUs: 20
Total Memory: 30.98GiB
Name: li-6eb4574c-3645-11b2-a85c-c553fdac6eee.ibm.com
ID: eebd6ca3-fc96-44a4-84b5-687fb111c1df
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
No response