"podman create" prepends ENTRYPOINT to CMD

[matpen]

Is this a BUG REPORT or FEATURE REQUEST? (leave only one on its own line)

/kind bug

Description

When running podman create the ENTRYPOINT is prepended (hardcoded) to the CMD. If the container is committed to an image, this change is preserved, which means that the entrypoint will be run multiple times.

Steps to reproduce the issue:

Please see the attached script which performs the following steps:

1. Start with a dummy image with an ENTRYPOINT and a CMD

2. podman create a container from the image

3. podman inspect the container and observe the CMD

Describe the results you received:

The final CMD is the result of the concatenation of ENTRYPOINT + CMD.

Describe the results you expected:

The CMD should not be changed.

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

Note that the issue only happens with podman create. Buildah seems not affected (see last step in the above script).

Output of podman version:

Version:            1.4.2
RemoteAPI Version:  1
Go Version:         go1.12
Git Commit:         9b6a98cfd7813513e5697888baa93318395a2055
Built:              Fri Jun 28 22:48:29 2019
OS/Arch:            linux/amd64

Output of podman info --debug:

debug:
  compiler: gc
  git commit: 9b6a98cfd7813513e5697888baa93318395a2055
  go version: go1.12
  podman version: 1.4.2
host:
  BuildahVersion: 1.9.0
  Conmon:
    package: Unknown
    path: /usr/local/libexec/crio/conmon
    version: 'conmon version 0.3.0, commit: 8455ce1ef385120deb827d0f0588c04357bad4c4'
  Distribution:
    distribution: ubuntu
    version: "16.04"
  MemFree: 4695924736
  MemTotal: 16684040192
  OCIRuntime:
    package: 'runc: /usr/sbin/runc'
    path: /usr/sbin/runc
    version: 'runc version spec: 1.0.1-dev'
  SwapFree: 16997703680
  SwapTotal: 17036734464
  arch: amd64
  cpus: 8
  hostname: matteo-laptop
  kernel: 4.4.0-157-generic
  os: linux
  rootless: false
  uptime: 10h 48m 57.79s (Approximately 0.42 days)
registries:
  blocked: null
  insecure: null
  search: null
store:
  ConfigFile: /etc/containers/storage.conf
  ContainerStore:
    number: 129
  GraphDriverName: overlay
  GraphOptions: null
  GraphRoot: /home/matteo/MyData/data/podman/root
  GraphStatus:
    Backing Filesystem: extfs
    Native Overlay Diff: "true"
    Supports d_type: "true"
    Using metacopy: "false"
  ImageStore:
    number: 254
  RunRoot: /var/run/containers/storage
  VolumePath: /home/matteo/MyData/data/podman/root/volumes

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

Physical host (laptop) running Ubuntu 16.04.
All above commands (buildah, podman) run as root.

Buildah version:

Version:         1.9.1-dev
Go Version:      go1.12
Image Spec:      1.0.1
Runtime Spec:    1.0.0
CNI Spec:        0.4.0
libcni Version:  v0.7.0-rc2
Git Commit:      4d9da85
Built:           Fri Jun 28 19:21:49 2019
OS/Arch:         linux/amd64

[mheon]

The behaviour of create is correct; it's commit that's wrong here.

[mheon]

I'll take this one.

[chenzhiwei]

I encountered this issue too, podman will always use the entrypoint in the docker image and does not use the command or entrypoint in kube yaml file:

You can reproduce with following yaml file:

apiVersion: v1
kind: Pod
metadata:
  labels:
    app: nginx
  name: nginx
spec:
  containers:
  - command:
    - sleep
    - 100000
    image: docker.io/siji/nginx:latest
    name: app

Update:

Sorry, my issue was fixed here: 6f35a57

[mheon]

Hm. I might be wrong here. c.config.Command is being set incorrectly to the full command including entrypoint - it seems like create might be at fault after all.

[mheon]

#3744 to fix

[mheon]

Unfortunately, this will only catch newly-created containers - older ones will be stuck with the doubled entrypoint.