RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1097334 - docker error message consistency
Summary: docker error message consistency
Keywords:
Status: CLOSED DUPLICATE of bug 1097344
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: docker
Version: 7.0
Hardware: x86_64
OS: Linux
medium
low
Target Milestone: rc
: ---
Assignee: Sally
QA Contact: Virtualization Bugs
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-05-13 15:04 UTC by Chris Evich
Modified: 2019-03-06 00:46 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-07-07 18:52:58 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)

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 ***
Note You need to log in before you can comment on or make changes to this bug.