podman does not start container with CMD or ENTRYPOINT

[elijahsgh]

Is this a BUG REPORT or FEATURE REQUEST?:

[//]: # Uncomment only one, leave it on its own line:

kind bug

[//]: # kind feature

Description

podman run responds with No command specified on command line or as CMD or ENTRYPOINT in this image in an image built from a Dockerfile that includes ENTRYPOINT ["/opt/unitd/unitd", "--no-daemon", "--log", "/dev/stdout"]

$ podman inspect localhost/nginx-unit:1.1 | jq .[0].ContainerConfig.Entrypoint
[
  "/opt/unitd/unitd",
  "--no-daemon",
  "--log",
  "/dev/stdout"
]

Is podman ignoring the Entrypoint? This also happens if I use CMD.

Steps to reproduce the issue:

1. Build container from Dockerfile with ENTRYPOINT or CMD specified

2. Try to podman run the image

Describe the results you received:

ENTRYPOINT ["/opt/unitd/unitd", "--no-daemon", "--log", "/dev/stdout"]

Describe the results you expected:

The container should start.

Additional information you deem important (e.g. issue happens only occasionally):

Output of podman version:

$ podman version
Version:       0.9.1
Go Version:    go1.10.4
OS/Arch:       linux/amd64

Output of podman info:

host:
  Conmon:
    package: podman-0.9.1-3.gitaba58d1.fc28.x86_64
    path: /usr/libexec/podman/conmon
    version: 'conmon version 1.12.0-dev, commit: 1d75f1d54e9e123a97e7f505e38df7ab7192cfa7-dirty'
  MemFree: 1234755584
  MemTotal: 16811745280
  OCIRuntime:
    package: runc-1.0.0-51.dev.gitfdd8055.fc28.x86_64
    path: /usr/bin/runc
    version: 'runc version spec: 1.0.0'
  SwapFree: 8392011776
  SwapTotal: 8476684288
  arch: amd64
  cpus: 16
  hostname: desktop
  kernel: 4.18.10-200.fc28.x86_64
  os: linux
  uptime: 46h 4m 27.56s (Approximately 1.92 days)
insecure registries:
  registries: []
registries:
  registries:
  - docker.io
  - registry.fedoraproject.org
  - quay.io
  - registry.access.redhat.com
  - registry.centos.org
store:
  ContainerStore:
    number: 16
  GraphDriverName: vfs
  GraphOptions: []
  GraphRoot: /home/.local/share/containers/storage
  GraphStatus: {}
  ImageStore:
    number: 20
  RunRoot: /run/user/1000/run

Additional environment details (AWS, VirtualBox, physical, etc.):
Physical, Fedora 28

[mheon]

I'm going to bet this is a result of the array entrypoint - most images use a single element. Will confirm tomorrow.

[elijahsgh]

Using the CMD "command -to -run" format didn't solve it.

CMD "/opt/unitd/unitd --no-daemon --log /dev/stdout"

$ podman inspect 38d264acc067 | jq .[0].ContainerConfig.Cmd
[
  "/bin/sh",
  "-c",
  "\"/opt/unitd/unitd --no-daemon --log /dev/stdout\""
]

But I still get:

$ podman run -it 38d264acc067
No command specified on command line or as CMD or ENTRYPOINT in this image

[mheon]

Hm. The logic for generation looks right (override entrypoint with CLI --entrypoint flag if present, then append user-specified command (or CMD if no user command specified). This should work for any entrypoint format, array or not.

[mheon]

Trying to reproduce now

[mheon]

@tamarintech I'm having trouble reproducing locally - I can't reproduce with a Dockerfile or manually setting via --entrypoint. Can you provide a dockerfile that causes the error for you?

[elijahsgh]

FROM alpine:3.8 AS unitdbuild
RUN apk update
RUN apk add --no-cache \
        ca-certificates \
        build-base \
        gcc make \
        python3 \
        python3-dev \
        git
RUN git clone https://github.com/nginx/unit /unitd
WORKDIR /unitd
RUN ./configure
RUN ./configure python --config=python3-config
RUN make all
RUN stat build/unitd
RUN stat build/python3.unit.so

FROM alpine:3.8
WORKDIR /opt/unitd
RUN apk --no-cache add ca-certificates python3
RUN mkdir /opt/unitd/modules /opt/unitd/state
COPY --from=unitdbuild /unitd/build/unitd /opt/unitd/
COPY --from=unitdbuild /unitd/build/python3.unit.so /opt/unitd/modules/
CMD /opt/unitd/unitd --no-daemon --log /dev/stdout

[mheon]

Thanks, I'll try with that

[mheon]

Hm. Works for me on master - let me try the 0.9.1 tag

[mheon]

Works there too - but I was using the image build by master. Maybe it's the older Buildah version in 0.9.1 triggering it?

[elijahsgh]

Interesting, but in a :( way. Both are from Fedora 28.

$ buildah version
Version:         1.3
Go Version:      go1.10.3
Image Spec:      1.0.0
Runtime Spec:    1.0.0
CNI Spec:        0.3.1
libcni Version:  v0.6.0
Git Commit:      4888163
Built:           Sun Aug  5 06:31:55 2018
OS/Arch:         linux/amd64

[mheon]

0.9.1 seems old for F28 - there should be a 0.9.3 or so out. Could you try upgrading to that and rebuilding the image?

[elijahsgh]

That's the latest.

Sounds like it works fine in 0.9.3, though?

[mheon]

Wow, you're right... We definitely built 0.9.3.1 for F28, it must not have made it into the main repos.

Let me poke some people tomorrow and see about getting it out the door.

[mheon]

@tamarintech 0.9.3.1 should have just been pushed to stable, though it could take a few hours for it to show up in the repos