Calling Stop on a container in Created status reports error

[frivard-coveo]

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

/kind bug

Description

I'm trying to migrate our existing infrastructure from Docker to Podman, and at first some of our basic unit test are failing. The particular test case is to create a dummy container (not started), then call Stop on it. We expect a simple " no change" reply. Instead there is an error. I am even able to replicate this using the command-line instead of the REST api.

Steps to reproduce the issue:

1. podman create alpine bash

2. podman ps -a make sure it is CREATED

3. podman stop <container_id>.

Describe the results you received:

2021-09-24⏰15:38:35  ~ podman create alpine bash
Resolved "alpine" as an alias (/etc/containers/registries.conf.d/000-shortnames.conf)
Trying to pull docker.io/library/alpine:latest...
Getting image source signatures
Copying blob a0d0a0d46f8b done
Copying config 14119a10ab done
Writing manifest to image destination
Storing signatures
386a7f51f24b54c982aa7daf28c99b513b2c872d6d03bf63c985d0419ae27945
 2021-09-24⏰15:38:46 ~ podman ps -a
CONTAINER ID  IMAGE                            COMMAND     CREATED         STATUS      PORTS       NAMES
386a7f51f24b  docker.io/library/alpine:latest  bash        10 seconds ago  Created                 wizardly_swartz
 2021-09-24⏰15:38:56 ~ podman stop 386a7f51f24b
Error: can only stop created or running containers. 386a7f51f24b54c982aa7daf28c99b513b2c872d6d03bf63c985d0419ae27945 is in state configured: container state improper

Describe the results you expected:

2021-09-24⏰15:42:20 ~ docker create alpine bash
578d5f5f8895ce4233dc547843b5bf061526ba996cc3870a4f830c3ad342728d
 2021-09-24⏰15:42:24 ~docker ps -a
CONTAINER ID   IMAGE     COMMAND   CREATED         STATUS    PORTS     NAMES
578d5f5f8895   alpine    "bash"    3 seconds ago   Created             musing_booth
 2021-09-24⏰15:42:27 ~ docker stop 578d5f5f8895
578d5f5f8895

Additional information you deem important (e.g. issue happens only occasionally):
running in WSL2, Ubuntu 20.04, user 1000. I also tried with sudo podman and the behaviour is the same.

Output of podman version:

WARN[0000] "/" is not a shared mount, this could cause issues or missing mounts with rootless containers
Version:      3.3.1
API Version:  3.3.1
Go Version:   go1.16.6
Built:        Wed Dec 31 19:00:00 1969
OS/Arch:      linux/amd64

Output of podman info --debug:

host:
  arch: amd64
  buildahVersion: 1.22.3
  cgroupControllers: []
  cgroupManager: cgroupfs
  cgroupVersion: v1
  conmon:
    package: 'conmon: /usr/libexec/podman/conmon'
    path: /usr/libexec/podman/conmon
    version: 'conmon version 2.0.27, commit: '
  cpus: 8
  distribution:
    distribution: ubuntu
    version: "20.04"
  eventLogger: file
  hostname: WKS-001607
  idMappings:
    gidmap:
    - container_id: 0
      host_id: 1000
      size: 1
    - container_id: 1
      host_id: 100000
      size: 65536
    uidmap:
    - container_id: 0
      host_id: 1000
      size: 1
    - container_id: 1
      host_id: 100000
      size: 65536
  kernel: 5.10.16.3-microsoft-standard-WSL2
  linkmode: dynamic
  memFree: 10199347200
  memTotal: 12558262272
  ociRuntime:
    name: crun
    package: 'crun: /usr/bin/crun'
    path: /usr/bin/crun
    version: |-
      crun version 0.20.1.5-925d-dirty
      commit: 0d42f1109fd73548f44b01b3e84d04a279e99d2e
      spec: 1.0.0
      +SYSTEMD +SELINUX +APPARMOR +CAP +SECCOMP +EBPF +CRIU +YAJL
  os: linux
  remoteSocket:
    path: /tmp/podman-run-1000/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: true
    seccompEnabled: true
    seccompProfilePath: /usr/share/containers/seccomp.json
    selinuxEnabled: false
  serviceIsRemote: false
  slirp4netns:
    executable: /usr/bin/slirp4netns
    package: 'slirp4netns: /usr/bin/slirp4netns'
    version: |-
      slirp4netns version 1.1.8
      commit: unknown
      libslirp: 4.3.1-git
      SLIRP_CONFIG_VERSION_MAX: 3
      libseccomp: 2.4.3
  swapFree: 8589934592
  swapTotal: 8589934592
  uptime: 51m 0.38s
registries:
  search:
  - docker.io
  - quay.io
store:
  configFile: /home/coveo/.config/containers/storage.conf
  containerStore:
    number: 0
    paused: 0
    running: 0
    stopped: 0
  graphDriverName: overlay
  graphOptions:
    overlay.mount_program:
      Executable: /usr/bin/fuse-overlayfs
      Package: 'fuse-overlayfs: /usr/bin/fuse-overlayfs'
      Version: |-
        fusermount3 version: 3.9.0
        fuse-overlayfs: version 1.5
        FUSE library version 3.9.0
        using FUSE kernel interface version 7.31
  graphRoot: /home/coveo/.local/share/containers/storage
  graphStatus:
    Backing Filesystem: extfs
    Native Overlay Diff: "false"
    Supports d_type: "true"
    Using metacopy: "false"
  imageStore:
    number: 0
  runRoot: /tmp/podman-run-1000/containers
  volumePath: /home/coveo/.local/share/containers/storage/volumes
version:
  APIVersion: 3.3.1
  Built: 0
  BuiltTime: Wed Dec 31 19:00:00 1969
  GitCommit: ""
  GoVersion: go1.16.6
  OsArch: linux/amd64
  Version: 3.3.1

Package info (e.g. output of rpm -q podman or apt list podman):

Listing... Done
podman/unknown,now 100:3.3.1-1 amd64 [installed]
podman/unknown 100:3.3.1-1 arm64
podman/unknown 100:3.3.1-1 armhf
podman/unknown 100:3.3.1-1 s390x

Have you tested with the latest version of Podman and have you checked the Podman Troubleshooting Guide? (https://github.com/containers/podman/blob/master/troubleshooting.md)

Yes

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

[flouthoc]

@frivard-coveo above PR should close this.

[frivard-coveo]

Wow, thanks a lot for the quick fix !
Looking at the PR, I understand that this particular function won't return an error code anymore; is the REST API going to return 304 Not Modified status code?

[frivard-coveo]

I have built the code from source, and I confirm that PR #11754 fixes this issue.
The version returned from my build with podman version is 4.0.0-dev : does it mean that this fix will be released only as part of the next major version?

[flouthoc]

@frivard-coveo yes this should show up in next release :)