Bug 1097334

Summary:	docker error message consistency
Product:	Red Hat Enterprise Linux 7	Reporter:	Chris Evich <cevich>
Component:	docker	Assignee:	Sally <somalley>
Status:	CLOSED DUPLICATE	QA Contact:	Virtualization Bugs <virt-bugs>
Severity:	low	Docs Contact:
Priority:	medium
Version:	7.0	CC:	cevich, dwalsh
Target Milestone:	rc	Keywords:	Extras
Target Release:	---
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2015-07-07 18:52:58 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Chris Evich 2014-05-13 15:04:09 UTC

Description of problem:
All error-type messages sent to stderr should include the word "error" in them.

Version-Release number of selected component (if applicable):
docker-0.10.0-10.el7.x86_64

How reproducible:
Very

Steps to Reproduce:
1. # docker run --foreground fedora:20 bash
2. # docker run --foreground this_image_does_not_exist bash

Actual results:
Can't start container: Foreground mode not supported in user session
Unable to find image 'this_image_does_not_exist' locally

Expected results:
Docker-Error: Can't start container: Foreground mode not supported in user session
Docker-Error: Unable to find image 'this_image_does_not_exist' locally

Additional info:
This is a problem when scripting 'docker run' because you can't rely on exit codes to signal docker-CLI problems.  Exit codes must be preserved from the contained-process(s), for cases where the script needs to access them.  Therefor, a script's only option is to key off of some standard string content in the error message itself.  The less-likely that standard-string is to appear in contained-process(s) stderr, the better.

Additional Additional info:
Setting to high because CI testing also needs reliable way to distinguish between contained-process exit codes and docker CLI errors.

Comment 1 Chris Evich 2014-05-13 15:19:19 UTC

Note: See also Bug 1097344.  One or the other should be fixed ASAP for CI testing purposes.

Comment 2 Daniel Walsh 2014-05-19 18:03:07 UTC

https://github.com/dotcloud/docker/issues/354

Discusses this as expected behaviour.  One of the bugs suggests doing what chroot does.

   Exit status:

     125 if 'chroot' itself fails
     126 if COMMAND is found but cannot be invoked
     127 if COMMAND cannot be found
     the exit status of COMMAND otherwise

What do you think?

Comment 3 Chris Evich 2014-05-19 20:26:16 UTC

Thanks for asking.

That could work, unless we care about supporting exit status from the 'chroot' command inside a container.  TBH, the most recent comment sounds better: ``All non-zero exit codes are mapped to 255 for me in 0.8.1``.  Though only because I'd guess that has less of a chance to 'clash' with expected codes from w/in a container.  But that's a total guess.

The other way to handle this (suggested above) is to guarantee some docker-specific 'error-indicator' text always appears on stderr.  The benefit being, a specific static string is **much** less likely to clash with a legit return code coming from within the container.  Since we can never predict how anybody will usse return codes within.

Either way would suit our testing needs, so deferring to the best community-supplied mitigation option is fine.

Comment 4 Chris Evich 2014-05-19 20:40:13 UTC

Note: The exit code above more relates to bug 1097344 'Docker run exit code consistency'

This bug really just has to do with the error message text.  Though feel free to close one and merge them into the same issue, I wasn't sure how much of a distinction to draw, since there's no harm in fixing both :D

Comment 5 Daniel Walsh 2014-06-27 16:43:16 UTC

Yes wrong bug.

Comment 6 Daniel Walsh 2014-06-27 16:56:19 UTC

One thing we could do is allow you to specify a log message prefix.

something like

docker --prefix="DockerLog: "

Then most messages from docker would look like

 docker run -ti -v /var/lib/test:/var/lib/test:z fedora1 /bin/sh
DockerLog: 2014/06/27 12:54:29 Cannot connect to the Docker daemon. Is 'docker -d' running on this host?

Comment 7 Chris Evich 2014-06-27 17:57:11 UTC

That would be super-duper handy if/when there is ever a situation of multiple docker daemons running on a single host or with remote-logging.  I like it!

Still for consistency, it's nice to have key-words like 'Error' or 'Warning' allways appear in such messages coming from docker.  It also helps in the sense that you know right away if it's something to worry about or not (i.e. warning vs error).

Comment 8 Daniel Walsh 2014-06-27 19:23:48 UTC

Well the problem I have is trying to get this upsteam might be difficult.

Comment 9 Chris Evich 2014-06-27 19:57:20 UTC

Maybe we should open separate RFE for that --prefix idea?

Let's keep this bug tied to 'Error/Warning' appearing in error/warning messages consistently.  I can lower this to 'low' now, since work on bug 354 really is much more helpful in terms of automation.

Comment 14 Chris Evich 2015-01-27 17:16:55 UTC

Just to clarify:


This bug is for all sub-commands not using consistent language in error/warning messages.  Minor issue IMHO.

Bug 1097344 is strictly for the run sub-command, since it needs special treatment. This issue is pretty important IMHO.

Bug 1162807 is about non-run sub-commands, It's verified fixed in 1.4.1-25.

Comment 17 Sally 2015-07-07 18:52:58 UTC


*** This bug has been marked as a duplicate of bug 1097344 ***