New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Image Inheritance issue with Entrypoint/Cmd #5147

Closed
cpuguy83 opened this Issue Apr 10, 2014 · 26 comments

Comments

Projects
None yet
10 participants
@cpuguy83
Contributor

cpuguy83 commented Apr 10, 2014

# Image my_debian
FROM debian
CMD ["/bin/bash"]
# image deb_echo
FROM my_debian
ENTRYPOINT ["/bin/echo", "foo"]
docker run deb_echo
=> foo /bin/bash

This is a problem, I think.
Cmd should be executed in the context of Entrypoint.
If Entrypoint changes, then Cmd is very likely no longer valid.
We can explicitly overwrite Cmd in the Dockerfile (or whatever), and maybe that's safest this late in the game, but it seems that Cmd should be set to nil if Entrypoint is changed.

Thoughts?

@fdemmer

This comment has been minimized.

fdemmer commented Apr 22, 2014

i am experiencing some weirdness when building images with dockerfiles, that may be related to this.

the docker file uses ADD to copy a config file and ENTRYPOINT to set the binary to run, but i do not set CMD. in the resulting image i can see via inspect, that "Cmd" is set to "/bin/sh", "-c", "#(nop) ADD file:341f95d3....

@cpuguy83

This comment has been minimized.

Contributor

cpuguy83 commented Apr 23, 2014

@fdemmer What Docker version are you on?
It's a slightly separate issue than this one for sure.

@fdemmer

This comment has been minimized.

fdemmer commented Apr 23, 2014

Client version: 0.9.1
Go version (client): go1.2.1
Git commit (client): 3600720

the one that currently comes with ubuntu trusty.

however, i tried to reproduce this just now, and failed. i still have the image with the issue:

        "Cmd": [
            "/bin/sh",
            "-c",
            "#(nop) ADD file:341f95d3047dc772de43b0c8b8671d59cd1268d4ecf819f76912cb1ea7f64498 in /etc/nginx/nginx.conf"
        ],
...
        "Entrypoint": [
            "nginx"
        ],

this "file:341f" was not the last ADD command performed in the history of the image, but a leftover from the build of the image used as FROM:

IMAGE               CREATED             CREATED BY                                      SIZE
fb23ba31d7ed        10 hours ago        /bin/sh -c cd /usr/share/nginx/www && git clo   220.6 kB
d8b7489d81e1        10 hours ago        /bin/sh -c #(nop) VOLUME /etc/ssl/private       0 B
a7347b239c3b        10 hours ago        /bin/sh -c #(nop) VOLUME /usr/share/nginx/www   0 B
01970784a5f6        10 hours ago        /bin/sh -c rm /etc/nginx/sites-enabled/defaul   77 B
99a383aec701        10 hours ago        /bin/sh -c #(nop) ADD file:af044fa52be5f4665d   851 B
1a290a11683d        10 hours ago        /bin/sh -c apt-get install -y git               71.01 MB
3e3ffbb387a2        10 hours ago        /bin/sh -c apt-get update                       149.4 kB
fad0e92db4af        10 hours ago        /bin/sh -c #(nop) ENV TERM=xterm                0 B
632ae07d3b4d        10 hours ago        /bin/sh -c #(nop) MAINTAINER Florian Demmer <   0 B
07a261825842        10 hours ago        /bin/sh -c #(nop) EXPOSE [80]                   0 B
009fb5e18862        10 hours ago        /bin/sh -c #(nop) ENTRYPOINT [nginx]            0 B
541b2ab07163        10 hours ago        /bin/sh -c #(nop) EXPOSE [443]                  0 B
331b0fb5eb9f        10 hours ago        /bin/sh -c #(nop) WORKDIR /etc/nginx            0 B
7a96ab4e23f8        10 hours ago        /bin/sh -c #(nop) VOLUME /var/log/nginx         0 B
ab921a28ae49        10 hours ago        /bin/sh -c #(nop) ADD file:341f95d3047dc772de   613 B
0c4a13a0f170        11 hours ago        /bin/sh -c apt-get install -y nginx             13.32 MB
e98d27b059f0        11 hours ago        /bin/sh -c apt-get update                       20.39 MB
34a432001492        12 hours ago        /bin/sh -c #(nop) ENV TERM=xterm                0 B
9f297ee04c21        12 hours ago        /bin/sh -c #(nop) MAINTAINER Florian Demmer <   0 B
c0fe63f9a4c1        13 days ago         /bin/sh -c apt-get update && apt-get install    26.37 MB
79fdb1362c84        13 days ago         /bin/sh -c #(nop) ADD file:0125346f2266564e00   204.7 MB
6170bb7b0ad1        11 weeks ago        /bin/sh -c #(nop) MAINTAINER Tianon Gravi <ad   0 B
511136ea3c5a        10 months ago                                                       0 B

i'll try to find out more if it happens again and with a more recent version.

edit 2014-07-27: actually what i saw was probably this issue: #3762

@crosbymichael crosbymichael added this to the 1.0 milestone May 16, 2014

@djmaze

This comment has been minimized.

Contributor

djmaze commented May 19, 2014

Having exactly the same problem as @fdemmer. In this case the inherited image consists of a FROM line only. Multiple ONBUILD ADDs from the parent image are executed, but nothing more. When inspecting the container, I can see the same "/bin/sh", "-c", "#(nop) ADD ..." command.

I have to explictly add a CMD to the child Dockerfile in order to get the container running.

Client version: 0.11.0
Client API version: 1.11
Go version (client): go1.2.1
Git commit (client): 15209c3-dirty
Server version: 0.11.0
Server API version: 1.11
Git commit (server): 15209c3-dirty
Go version (server): go1.2.1
Last stable version: 0.11.1, please update docker

@crosbymichael crosbymichael added the bug label May 19, 2014

@vieux

This comment has been minimized.

Collaborator

vieux commented May 19, 2014

Hi,

This is working as expected. It's weird, and it'll be fixed, but after 1.0, when we will include much bigger changes on the Dockerfile side.
When using ENTRYPOINT, you should see the CMD as default "args", not default "cmd"
So the img.cmd became ENTRYPOINT + CMD ("/bin/echo", "foo" + "/bin/bash")

See for more information: http://docs.docker.io/reference/builder/#entrypoint

I would say right now that ENTRYPOINT and CMD are rather incompatible, so if you inherit from an image with a CMD, override using a CMD

@vieux vieux closed this May 19, 2014

@cpuguy83

This comment has been minimized.

Contributor

cpuguy83 commented May 20, 2014

@vieux I get that they are default args, but the problem is that if the entrypoint is changed, those default args usually won't make sense anymore.

@vieux

This comment has been minimized.

Collaborator

vieux commented May 20, 2014

We know that, I'm just saying we won't change (and break some images) now to break again in a few month.

@vieux

This comment has been minimized.

Collaborator

vieux commented May 20, 2014

It's not blocking, just use CMD when you inherit a CMD and you are "good"

*Note I used "

@cpuguy83

This comment has been minimized.

Contributor

cpuguy83 commented May 20, 2014

Ok, makes sense.

@vieux vieux reopened this Jun 17, 2014

@LK4D4

This comment has been minimized.

Contributor

LK4D4 commented Jun 17, 2014

@shykes What are you think about this? I think this should be fixed.

@shykes

This comment has been minimized.

Collaborator

shykes commented Jun 18, 2014

I think this makes sense, but we already discussed this with @vieux and I forgot the conclusion.

I will defer to @vieux.

Please keep in mind reverse compatibility, whatever you decide.

@LK4D4

This comment has been minimized.

Contributor

LK4D4 commented Jul 6, 2014

ping @vieux

@vieux vieux modified the milestones: 1.1.1, 1.0 Jul 7, 2014

@vieux

This comment has been minimized.

Collaborator

vieux commented Jul 7, 2014

It's not possible to keep reverse compatibility unless we start versioning Dockerfile parser like we do for the API, but IMO, CMD and ENTRYPOINT should be not be use together.

When you set ENTRYPOINT it should erase and previous CMD and vice versa

@tianon

This comment has been minimized.

Member

tianon commented Jul 7, 2014

Oh please don't - I love using them together, especially since I use ENTRYPOINT as my ONSTART. :P

@tianon

This comment has been minimized.

Member

tianon commented Jul 7, 2014

@vieux

This comment has been minimized.

Collaborator

vieux commented Jul 7, 2014

@tianon what is the difference with
ENTRYPOINT ["/usr/src/wordpress/docker-entrypoint.sh", "apache2", "-DFOREGROUND"] ?

@tianon

This comment has been minimized.

Member

tianon commented Jul 7, 2014

The difference is that I can docker run -it wordpress bash and actually get a shell.

@LK4D4

This comment has been minimized.

Contributor

LK4D4 commented Jul 7, 2014

If we using ENTRYPOINT and override CMD it's ok as for me. For example:

FROM crosbymichael/redis-cli

CMD ["info"]

But overriding ENTRYPOINT with saving CMD it's not ok. For example

FROM crosbymichael/redis

ENTRYPOINT ["bash"]

and here we get command like:

["bash",  "--bind", "0.0.0.0", "--save", "900", "1", "--save", "300", "10", "--save", "60", "10000", "--dir", "/redis"]
  • pretty weird.
@tianon

This comment has been minimized.

Member

tianon commented Jul 7, 2014

Yeah, I could agree with what @LK4D4 is proposing.

@vieux

This comment has been minimized.

Collaborator

vieux commented Jul 7, 2014

I agree, @LK4D4 could you try to implement that ?

@LK4D4

This comment has been minimized.

Contributor

LK4D4 commented Jul 8, 2014

@vieux Of course :) Will be pleased.

@wyaeld

This comment has been minimized.

wyaeld commented Jul 8, 2014

Should the behaviour of ignoring the parent Dockefiles CMD in this situation be silent. That seems a bit magical. I haven't seen whether we can have warnings emitted by the builder, but it seems useful to give people feedback.

Consider if:
Parent defines CMD, Child defines ENTRYPOINT. Builder emits warning that CMD will be ignored and should be overridden. (Still builds the image though)
Parent defines CMD, Child defines ENTRYPOINT & CMD. Builder is satisfied.

That way its a little more transparent.

@sfitts

This comment has been minimized.

sfitts commented Jul 11, 2014

Just adding my $0.02 that this is horribly confusing. Here is my personal example:

I'm using the image "debian:wheezy" as my base image (somewhat at the suggestion of @crosbymichael). My assumption is that this a "clean" OS only image (ala the ubuntu images). I then proceed to use it as the basis for a mongo image with a Dockerfile that looks like this:

FROM debian:wheezy

... stuff to install mongo...

EXPOSE 27017
ENTRYPOINT ["/usr/bin/mongod"]

When I run the resulting image it fails with mongo complaining about an illegal parameter "/bin/bash". My first reaction is WT*? After poking around a bit I do an inspect and sure enough it shows that CMD is set to /bin/bash, I guess for convenience of launching the base image directly.

For me this highlights the main issue -- inconsistency. I have no way of knowing what choices/conventions were used by the image I'm using. The base ubuntu images don't specify CMD, but apparently the debian ones do. That's the kind of knowledge I shouldn't need to have when building my own image. At least providing some visible warning as suggested by @wyaeld would be nice.

Also, I must have misunderstood the earlier comment about not mixing ENTRYPOINT and CMD. I do this all the time and I thought it was a recommended pattern. It is very useful for setting up default arguments to a service, but still allowing them to be overridden when necessary on the command line.

@cpuguy83

This comment has been minimized.

Contributor

cpuguy83 commented Jul 11, 2014

@sfitts The linked PR pretty much takes care of this.

Essentially if entrypoint is changed it resets cmd.

@sfitts

This comment has been minimized.

sfitts commented Jul 11, 2014

Sounds great -- I thought there was some discussion about not taking this right now due to compatibility concerns. But if I misread then my bad (if not then I'd like to at least see some interim solution that provides more visibility).

@cpuguy83

This comment has been minimized.

Contributor

cpuguy83 commented Jul 11, 2014

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment