Repository navigation
canceling "docker volume prune" does not consistently print a newline, and exits with non-zero status #4850
Description
Description
When terminating docker volume prune using CTRL-C, the CLI terminates, but no newline is printed at the end, causing the shell to continue on the same line. It also exits with a non-zero exit code (255). Behavior is inconsistent between shells though (perhaps some shells compensate for the missing newline, and add them implicitly?).
Reproduce
On Bash on macOS (very old one shipping with macOS);
bash-3.2$ docker volume prune
WARNING! This will remove anonymous local volumes not used by at least one container.
Are you sure you want to continue? [y/N] ^Cbash-3.2$ echo $?
255
bash-3.2$Using N (don't prune) or ENTER (default: also N), the CLI terminates cleanly with a zero exit-code (but also prints a message, which likely shouldn't be printed 😅);
bash-3.2$ docker volume prune
WARNING! This will remove anonymous local volumes not used by at least one container.
Are you sure you want to continue? [y/N] N
Total reclaimed space: 0B
bash-3.2$ echo $?
0Interestingly, on a more current version of Bash () on Linux, a newline is printed, but the exit-code is also non-zero, but different (130);
root@debian-s-1vcpu-1gb-ams3-01:~# docker volume prune
WARNING! This will remove anonymous local volumes not used by at least one container.
Are you sure you want to continue? [y/N] ^C
root@debian-s-1vcpu-1gb-ams3-01:~# echo $?
130
root@debian-s-1vcpu-1gb-ams3-01:~# bash --version
GNU bash, version 5.2.15(1)-release (x86_64-pc-linux-gnu)
Copyright (C) 2022 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software; you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.On zsh (default now on macOS), a newline is printed, but also exits with a non-zero exit code;
thajeztah@m1book ~ % docker volume prune
WARNING! This will remove anonymous local volumes not used by at least one container.
Are you sure you want to continue? [y/N] ^C%
thajeztah@m1book ~ % echo $?
255
thajeztah@m1book ~ %And same for Fish;
~ docker volume prune
WARNING! This will remove anonymous local volumes not used by at least one container.
Are you sure you want to continue? [y/N] ^C⏎
! ~ echo $status
255
~ Expected behavior
I expect a newline to be printed, and the command to exit with a zero exit status.
docker version
Client:
Cloud integration: v1.0.35+desktop.10
Version: 25.0.1
API version: 1.44
Go version: go1.21.6
Git commit: 29cf629
Built: Tue Jan 23 23:06:12 2024
OS/Arch: darwin/arm64
Context: desktop-linux
Server: Docker Desktop 4.28.0 (135377)
Engine:
Version: 25.0.1
API version: 1.44 (minimum version 1.24)
Go version: go1.21.6
Git commit: 71fa3ab079ec13d17257f86fa92db8d7f24802f1
Built: Wed Jan 24 09:49:39 2024
OS/Arch: linux/arm64
Experimental: false
containerd:
Version: 1.6.27
GitCommit: a1496014c916f9e62104b33d1bb5bd03b0858e59
runc:
Version: 1.1.11
GitCommit: v1.1.11-0-g4bccb38
docker-init:
Version: 0.19.0
GitCommit: de40ad0docker info
not relevantAdditional Info
No response
Activity
thaJeztah commentedon Feb 4, 2024
cc @laurazard @krissetto
thaJeztah commentedon Feb 4, 2024
Ah! 🤦 🤦 🤦
This looks to be another issue with
compose-cli. When calling the CLI directly, the newline issue work as expected. It also shows the difference in exit-status; without thecompose-cliwrapper, it exits with130(but we still need to look why it's not a zero exit code!);
laurazard commentedon Feb 4, 2024
Hmm, the exit code issue is interesting I guess. Since we're in a confirmation dialogue, I guess your intuition is that a CTRL-C = "user said no, valid input" exit 0, but otoh strictly from the technical perspective one situation is "we prompted the user for a question and the user replied" and the other is "we prompted the user for a question and in the meantime received a SIGINT". Do we have this behavior with all our confirmation dialogues?
thaJeztah commentedon Feb 4, 2024
Yeah, we should definitely look what conventions (or recommendations) are for this (perhaps POSIX or elsewhere defines some?)
I guess the TL;DR here is that
CTRL-Cwas my instinctive reaction "oh, no, let's not do that". Which of course is the lazy way of "what options must I pick / key must I press to cancel this operation?"In this case, I (instinctively) would expect "no action is taken (yet), other than asking the user to confirm", which likely wouldn't really warrant a forceful termination (3 strikes, you're out).
Not sure what the behavior would expected to be though once the pruning started (which can take some time to run!). To some extent, I'm tempted to say that (given it's a server-side operation), it'd still be fine for the client to terminate (and disconnect) immediately, because the server (daemon) should be responsible for gracefully handling that. But of course "it depends" (if the client also has to do graceful termination) 😂 so... likely...
buildx(in this case) is the best judge here.w.r.t. the
130exit code; wondering if that's a bug somewhere (e.g. converting acontext.Cancellederror into "whatever"). The255exit-status produced bycompose-cliis probably a side-effect of this (it may have logic to convert any "non-zero" status code from the executed (CLI) binary.(Wondering if
255here is-1and an integer overflow 😂 - I recall we had some old code using-1in some spots)krissetto commentedon Feb 19, 2024
I don't think POSIX defines a standard for the use of SIGINT signals at a user confirmation prompt. If the signals are uncaught, i've seen the 128+signal number used as a convention (could that be our 130 result?) but maybe further testing with common tools is warranted.
Generally I'd agree with considering CTRL+C as an equivalent of inputting
n/Nat a confirmation prompt, and trying to standardize whatever approach we decide on going withBenehiko commentedon Feb 21, 2024
I can take a jab at this