exec: "sleep 86400": executable file not found in $PATH about imagebuilder HOT 9 OPEN

The container image builder creates has to have something to hold it open. All RUN commands are from exec.

I did a docker run equivalent and it worked for me. Not sure what the difference is.

from imagebuilder.

Issues go stale after 90d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
Exclude this issue from closing by commenting /lifecycle frozen.

If this issue is safe to close now please do so with /close.

/lifecycle stale

from imagebuilder.

Stale issues rot after 30d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.
Exclude this issue from closing by commenting /lifecycle frozen.

If this issue is safe to close now please do so with /close.

/lifecycle rotten
/remove-lifecycle stale

from imagebuilder.

Rotten issues close after 30d of inactivity.

Reopen the issue by commenting /reopen.
Mark the issue as fresh by commenting /remove-lifecycle rotten.
Exclude this issue from closing again by commenting /lifecycle frozen.

/close

from imagebuilder.

@openshift-bot: Closing this issue.

from imagebuilder.

/reopen
it's still a problem and causing some amount of grief in OSBS builds, FWIW

from imagebuilder.

@sosiouxme: Reopened this issue.

from imagebuilder.

/remove-lifecycle rotten
/lifecycle frozen

from imagebuilder.

imagebuilder keeps track of the command and entrypoint of the base image, and when it encounters a Dockerfile instruction for changing them, it makes note of them. As @smarterclayton mentioned, it has to supply the engine with some command to make the working container idle so that it can use the "exec" engine API call to handle RUN instructions. Then, at commit-time, imagebuilder supplies the engine either with the value it retrieved from the base image, or the updated value it was given in the Dockerfile.

In the example we're seeing, the base image, fedora:27, doesn't supply an entrypoint or command. Because the build includes a RUN instruction, the working container is created and started with a dummy command ("sleep 86400"). At commit-time, imagebuilder supplies an image configuration structure to the engine where, because the base image didn't supply a value, and the Dockerfile didn't either, the command and entrypoint fields remain blank. The engine starts with the container's configuration, overwrites fields in it with fields that are set in the the image configuration it got from imagebuilder, and writes the image. The method for merging the configuration the client supplies at commit-time with the configuration of the container means that certain fields like the command, entrypoint, and user can't be unset or cleared. They can only be changed to some other non-empty value.

The combination of not having a command in the base image and having RUN instructions is what's triggering the problem, but I don't see any way to clear the field at commit-time in the engine API.

Possible workarounds would be to either not use RUN instructions (imagebuilder doesn't set a command unless it needs to start the working container, and it doesn't need to start a container unless it needs to use an exec call to run a command in it), make sure the base image specifies a command (apparently fedora did starting with fedora:28), or always specify a command in a Dockerfile, even if it's just a CMD ["/bin/bash"].

There's probably an argument to be made that imagebuilder should be supplying a default command and entrypoint when the base image doesn't include one, but I haven't worked out how it would impact tests.

from imagebuilder.