Repository navigation
Review rm behavior #7076
Description
Activity
It Breaks Log Parsing: If one writes an automated monitoring agent (like Datadog or a simple log scraper) to watch server logs for the string "Error response from daemon", it will trigger a false-positive alert every time a clean, successful container purge script runs.
FWIW, on the daemon side, no error would be logged; this would only appear if debug-logs are enabled, in which case error-response / statuses are logged at debug level;
INFO[2026-06-29T11:17:52.558910255Z] Daemon has completed initialization INFO[2026-06-29T11:17:52.558940255Z] API listen on /var/run/docker.sock DEBU[2026-06-29T11:18:08.694215388Z] handling HEAD request method=HEAD module=api request-url=/_ping vars="map[]" DEBU[2026-06-29T11:18:08.695719429Z] handling DELETE request method=DELETE module=api request-url="/v1.54/containers/nonexistent?force=1" vars="map[name:nonexistent version:1.54]" DEBU[2026-06-29T11:18:08.696226721Z] error response for DELETE request error-response="No such container: nonexistent" method=DELETE module=api request-url="/v1.54/containers/nonexistent?force=1" status=404 vars="map[name:nonexistent version:1.54]"
It Destroys Trust in set -e: Developers use set -e specifically so they don't have to manually write error checking after every single line of code. By making a command print a blatant error but return a success code, Docker actively gaslights the shell environment.
Yeah, ISTR that (maybe not captured in the ticket) there were some concerns about making it fully silent, because previously it would show the error. If that's still a concern, we could try to rewrite the error into a warning (
WARNING: container X not found), but maybe we should just skip all output for "not found" errors; looks like we do the same for networks (#3547)docker network rm nosuchnetwork Error response from daemon: network nosuchnetwork not found exit status 1 docker network rm -f nosuchnetwork # no output
Orthogonal, but looks like there's also some inconsistency with volumes, for which we print the volume's reference, even if it doesn't exist;
docker volume rm nosuchvolume Error response from daemon: get nosuchvolume: no such volume docker volume rm -f nosuchvolume nosuchvolume
@thaJeztah > FWIW, on the daemon side, no error would be logged
Thanks for clarification
Description
In the #2677 a choice was made to return 0 in case container doesn't exist.
Good intention, terrible execution, 0 exit code is returned but error is printed to console
Why this is bad
It Breaks Log Parsing: If one writes an automated monitoring agent (like Datadog or a simple log scraper) to watch server logs for the string "Error response from daemon", it will trigger a false-positive alert every time a clean, successful container purge script runs.
It Destroys Trust in set -e: Developers use set -e specifically so they don't have to manually write error checking after every single line of code. By making a command print a blatant error but return a success code, Docker actively gaslights the shell environment.
It Introduces Deception: it forces developers to write wildly over-engineered safety guards (like parsing docker inspect --type=container) just to protect their scripts from Docker’s internal exit-code lying.
If a tool prints the word "Error", it should emit an error code. If it returns "Success", it should shut up. Docker trying to do both at the same time is bad API design, plain and simple.
Reproduce
docker rm -f nonexistent
echo "DEBUG: 'docker rm' exited with code: $?"
Result:
Error response from daemon: No such container: nonexistent
DEBUG: 'docker rm' exited with code: 0
Expected behavior
On 0 return code no error message should be produced
docker version
Client: Version: 29.4.0-ce API version: 1.54 Go version: go1.26.3 Git commit: daa0cb7f23 Built: Wed May 6 04:59:34 2026 OS/Arch: linux/amd64 Context: default Server: Engine: Version: 29.4.0-ce API version: 1.54 (minimum version 1.40) Go version: go1.26.3 Git commit: daa0cb7f23 Built: Wed May 6 04:59:34 2026 OS/Arch: linux/amd64 Experimental: false containerd: Version: v1.7.29 GitCommit: 442cb34bda9a6a0fed82a2ca7cade05c5c749582 runc: Version: 1.4.1 GitCommit: v1.4.1-0-gc67132530367 docker-init: Version: 0.2.1_catatonit GitCommit:docker info
Additional Info
No response