Behavior of podman run --cidfile foo.cid is not compatible with docker run --cidfile foo.cid

[tom-tan]

Issue Description

The official document says:

Podman provides a command line interface (CLI) familiar to anyone who has used the Docker Container Engine. Most users can simply alias Docker to Podman (alias docker=podman) without any problems.

Therefore, we expect that Podman with an option behaves as same as Docker with the same option if possible.

In the case of Docker, the run subcommand with --cidfile option generates a file with CID and leaves it as is when the container instance terminated.
I confirmed that Podman 4.3.1 and earlier behaves as same as Docker, that is, the run subcommand with --cidfile generates a file and leave it as is when the instance terminated.

On the other hand, Padman 4.4.1 and later behaves differently. That is, the run subcommand with --cidfile generates a file but removed when the instance terminated.

This behavior change breaks existing tools such as cwltool, that is an executor of scientific workflows written in the Common Workflow Language.
In the case of cwltool, it executes containerized scientific tools with Podman and reports the detailed information such as CIDs after finishing the execution. Since Podman 4.4.1, cwltool fails to collect the CIDs and thus fails to execute a given workflow.

Is this behavior change a bug (i.e., unintended) or is it intended behavior change?
If intended, it is helpful if there is a list of such inconsistent behaviors with Docker.
Also it would be nice if the changelog mentions such breaking changes.

Steps to reproduce the issue

Execute the following commands:

$ podman run --rm -it --cidfile foo.cid alpine sleep 1
$ test -e foo.cid
$ echo $?

Describe the results you received

Since Podman v4.4.1, I received the following:

$ podman run --rm -it --cidfile foo.cid alpine sleep 1
...
$ test -e foo.cid
$ echo $?
1

That is, foo.cid is removed after finishing the execution.
It is inconsistent behavior with Docker.

Describe the results you expected

Here is a message I expected and I got from Podman v4.3.1 and earlier:

$ podman run --rm -it --cidfile foo.cid alpine sleep 1
...
$ test -e foo.cid
$ echo $?
0

That is, foo.cid remains after finishing execution.
This behavior is compatible with Docker.

podman info output

Podman 5.0.3 in Podman Desktop v1.10.3:


$ podman info
host:
  arch: arm64
  buildahVersion: 1.35.4
  cgroupControllers:
  - cpuset
  - cpu
  - io
  - memory
  - pids
  - rdma
  - misc
  cgroupManager: systemd
  cgroupVersion: v2
  conmon:
    package: conmon-2.1.10-1.fc40.aarch64
    path: /usr/bin/conmon
    version: 'conmon version 2.1.10, commit: '
  cpuUtilization:
    idlePercent: 97.88
    systemPercent: 0.53
    userPercent: 1.6
  cpus: 5
  databaseBackend: sqlite
  distribution:
    distribution: fedora
    variant: coreos
    version: "40"
  eventLogger: journald
  freeLocks: 2042
  hostname: localhost.localdomain
  idMappings:
    gidmap: null
    uidmap: null
  kernel: 6.8.8-300.fc40.aarch64
  linkmode: dynamic
  logDriver: journald
  memFree: 601247744
  memTotal: 15563984896
  networkBackend: netavark
  networkBackendInfo:
    backend: netavark
    dns:
      package: aardvark-dns-1.10.0-1.fc40.aarch64
      path: /usr/libexec/podman/aardvark-dns
      version: aardvark-dns 1.10.0
    package: netavark-1.10.3-3.fc40.aarch64
    path: /usr/libexec/podman/netavark
    version: netavark 1.10.3
  ociRuntime:
    name: crun
    package: crun-1.14.4-1.fc40.aarch64
    path: /usr/bin/crun
    version: |-
      crun version 1.14.4
      commit: a220ca661ce078f2c37b38c92e66cf66c012d9c1
      rundir: /run/crun
      spec: 1.0.0
      +SYSTEMD +SELINUX +APPARMOR +CAP +SECCOMP +EBPF +CRIU +LIBKRUN +WASM:wasmedge +YAJL
  os: linux
  pasta:
    executable: /usr/bin/pasta
    package: passt-0^20240426.gd03c4e2-1.fc40.aarch64
    version: |
      pasta 0^20240426.gd03c4e2-1.fc40.aarch64-pasta
      Copyright Red Hat
      GNU General Public License, version 2 or later
        <https://www.gnu.org/licenses/old-licenses/gpl-2.0.html>
      This is free software: you are free to change and redistribute it.
      There is NO WARRANTY, to the extent permitted by law.
  remoteSocket:
    exists: true
    path: /run/podman/podman.sock
  security:
    apparmorEnabled: false
    capabilities: CAP_CHOWN,CAP_DAC_OVERRIDE,CAP_FOWNER,CAP_FSETID,CAP_KILL,CAP_NET_BIND_SERVICE,CAP_SETFCAP,CAP_SETGID,CAP_SETPCAP,CAP_SETUID,CAP_SYS_CHROOT
    rootless: false
    seccompEnabled: true
    seccompProfilePath: /usr/share/containers/seccomp.json
    selinuxEnabled: true
  serviceIsRemote: true
  slirp4netns:
    executable: /usr/bin/slirp4netns
    package: slirp4netns-1.2.2-2.fc40.aarch64
    version: |-
      slirp4netns version 1.2.2
      commit: 0ee2d87523e906518d34a6b423271e4826f71faf
      libslirp: 4.7.0
      SLIRP_CONFIG_VERSION_MAX: 4
      libseccomp: 2.5.3
  swapFree: 0
  swapTotal: 0
  uptime: 25h 43m 21.00s (Approximately 1.04 days)
  variant: v8
plugins:
  authorization: null
  log:
  - k8s-file
  - none
  - passthrough
  - journald
  network:
  - bridge
  - macvlan
  - ipvlan
  volume:
  - local
registries:
  search:
  - docker.io
store:
  configFile: /usr/share/containers/storage.conf
  containerStore:
    number: 3
    paused: 0
    running: 2
    stopped: 1
  graphDriverName: overlay
  graphOptions:
    overlay.imagestore: /usr/lib/containers/storage
    overlay.mountopt: nodev,metacopy=on
  graphRoot: /var/lib/containers/storage
  graphRootAllocated: 99252940800
  graphRootUsed: 15805689856
  graphStatus:
    Backing Filesystem: xfs
    Native Overlay Diff: "false"
    Supports d_type: "true"
    Supports shifting: "true"
    Supports volatile: "true"
    Using metacopy: "true"
  imageCopyTmpDir: /var/tmp
  imageStore:
    number: 81
  runRoot: /run/containers/storage
  transientStore: false
  volumePath: /var/lib/containers/storage/volumes
version:
  APIVersion: 5.0.3
  Built: 1715299200
  BuiltTime: Fri May 10 09:00:00 2024
  GitCommit: ""
  GoVersion: go1.22.2
  Os: linux
  OsArch: linux/arm64
  Version: 5.0.3

Podman in a container

No

Privileged Or Rootless

Rootless

Upstream Latest Release

Yes

Additional environment details

I confirmed it happens with the following environments:

• Podman 5.0.3 in Podman Desktop v1.10.3 (podman info is shown above)
• Podman 4.9.3 on Ubuntu 24.04 (installed from the universe repository).
• Podman container (quay.io/podman/stable) with the following tags: v4.4.1, v4.4.4, v4.6.2, v4.9.3, v4.9.4 and v5.1.1 on Podman 3.4.4 on Ubuntu 22.04 (installed from the universe repository)

I confirmed it does not happen (i.e., compatible behavior with Docker) with the following environments:

• Podman 3.4.4 on Ubuntu 22.04 (installed from the universe repository).
• Podman container (quay.io/podman/stable) with the following tags: v3.4.7, v4.2.1, and v4.3.1 on Podman 3.4.4 on Ubuntu 22.04

Additional information

Additional information like issue happens only occasionally or issue happens with a particular architecture or on a particular setting

[Luap99]

3fee351
#16387

Removing the file with the container seemed logical and given nobody reported it since then I must assume it really isn't that important.

The other question is what value do you expect to get out of a cidfile when the corresponding container has already been removed?

[mr-c]

@Luap99 We don't need the cidfile after execution, but we assumed it was there and we were trying to delete the cidfile without checking to see if it still existed; oops!

Can this be documented as a difference in behavior from Docker? Thanks!

[Luap99]

Where would you want this to be documented?

In general I prefer the way to not delete the file. Mainly because I am aware of at least two bugs due to the deletion logic:
#23203 and #21974

So not deleting the file would be much simpler for podman overall I am just not sure we can do such a change without breaking other users. Maybe something better left until a podman 6.0.

[mr-c]

Where would you want this to be documented?

I would expect a top-level page at named "Difference from the Docker CLI" or similar at https://docs.podman.io/en/latest/index.html ; and that this was hyperlinked to from the sentence "Support for a Docker-compatible CLI interface," in https://github.com/containers/podman?tab=readme-ov-file#overview-and-scope and

Bonus, each difference would also be listed on the respective manual page, for example: https://docs.podman.io/en/latest/markdown/podman-run.1.html

Thanks!

[rhatdan]

Seems like something that could be handled in https://github.com/containers/podman/blob/main/transfer.md at least.

[github-actions]

A friendly reminder that this issue had no activity for 30 days.