Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

podman stop -t -1 container-id issue #21811

Closed
mbhangui opened this issue Feb 25, 2024 · 1 comment · Fixed by #21826
Closed

podman stop -t -1 container-id issue #21811

mbhangui opened this issue Feb 25, 2024 · 1 comment · Fixed by #21826
Labels
kind/bug Categorizes issue or PR as related to a bug.

Comments

@mbhangui
Copy link

Issue Description

The online documentation for podman stop command says

--time, -t=seconds

Seconds to wait before forcibly stopping the container. Use -1 for
infinite wait.

However using -1 as timeout shows overflow or a 64bit unsigned integer and results in an immediate SIGKILL

$ podman stop -t -1 indimail-mta
WARN[0000] StopSignal SIGTERM failed to stop container indimail-mta in 18446744073709551615 seconds, resorting to SIGKILL
indimail-mta

Steps to reproduce the issue

Steps to reproduce the issue

  1. start any container
  2. stop the container using podman stop -1 container-id

Describe the results you received

immediate SIGKILL of the container

Describe the results you expected

Specifying -1 should result in letting the container stop when all processes stop

podman info output

host:
  arch: amd64
  buildahVersion: 1.33.5
  cgroupControllers:
  - cpu
  - io
  - memory
  - pids
  cgroupManager: systemd
  cgroupVersion: v2
  conmon:
    package: conmon-2.1.10-1.fc39.x86_64
    path: /usr/bin/conmon
    version: 'conmon version 2.1.10, commit: '
  cpuUtilization:
    idlePercent: 90.91
    systemPercent: 2.55
    userPercent: 6.55
  cpus: 3
  databaseBackend: boltdb
  distribution:
    distribution: fedora
    variant: workstation
    version: "39"
  eventLogger: journald
  freeLocks: 2010
  hostname: argos.indimail.org
  idMappings:
    gidmap:
    - container_id: 0
     host_id: 1000
      size: 1
    - container_id: 1
      host_id: 524288
      size: 65536
    uidmap:
    - container_id: 0
      host_id: 1000
      size: 1
    - container_id: 1
      host_id: 524288
      size: 65536
  kernel: 6.7.4-200.fc39.x86_64
  linkmode: dynamic
  logDriver: k8s-file
  memFree: 1061756928
  memTotal: 16674045952
  networkBackend: netavark
  networkBackendInfo:
    backend: netavark
    dns:
      package: aardvark-dns-1.10.0-1.fc39.x86_64
      path: /usr/libexec/podman/aardvark-dns
      version: aardvark-dns 1.10.0
    package: netavark-1.10.3-1.fc39.x86_64
    path: /usr/libexec/podman/netavark
    version: netavark 1.10.3
  ociRuntime:
    name: crun
    package: crun-1.14.3-1.fc39.x86_64
   path: /usr/bin/crun
    version: |-
      crun version 1.14.3
      commit: 1961d211ba98f532ea52d2e80f4c20359f241a98
      rundir: /run/user/1000/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^20240220.g1e6f92b-1.fc39.x86_64
    version: |
      pasta 0^20240220.g1e6f92b-1.fc39.x86_64-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: false
    path: /run/user/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
    rootless: true
    seccompEnabled: true
    seccompProfilePath: /usr/share/containers/seccomp.json
    selinuxEnabled: false
  serviceIsRemote: false
  slirp4netns:
    executable: /usr/bin/slirp4netns
    package: slirp4netns-1.2.2-1.fc39.x86_64
    version: |-
      slirp4netns version 1.2.2
      commit: 0ee2d87523e906518d34a6b423271e4826f71faf
      libslirp: 4.7.0
      SLIRP_CONFIG_VERSION_MAX: 4
      libseccomp: 2.5.3
  swapFree: 8398290944
  swapTotal: 8589930496
  uptime: 187h 32m 32.00s (Approximately 7.79 days)
  variant: ""
plugins:
  authorization: null
  log:
  - k8s-file
  - none
  - passthrough
  - journald
  network:
  - bridge
  - macvlan
 - ipvlan
  volume:
  - local
registries:
  search:
  - ghcr.io
  - docker.io
  - registry.fedoraproject.org
  - registry.redhat.io
  - registry.access.redhat.com
  - registry.centos.org
  - registry.opensuse.org
store:
  configFile: /home/mbhangui/.config/containers/storage.conf
  containerStore:
    number: 1
    paused: 0
    running: 0
    stopped: 1
  graphDriverName: overlay
  graphOptions: {}
  graphRoot: /home/mbhangui/.local/share/containers/storage
  graphRootAllocated: 498403901440
  graphRootUsed: 95119712256
  graphStatus:
    Backing Filesystem: btrfs
    Native Overlay Diff: "true"
    Supports d_type: "true"
    Supports shifting: "false"
    Supports volatile: "true"
    Using metacopy: "false"
  imageCopyTmpDir: /var/tmp
  imageStore:
    number: 1
  runRoot: /run/user/1000/containers
  transientStore: false
  volumePath: /home/mbhangui/.local/share/containers/storage/volumes
version:
  APIVersion: 4.9.3
  Built: 1708357294
  BuiltTime: Mon Feb 19 21:11:34 2024
  GitCommit: ""
  GoVersion: go1.21.7
  Os: linux
  OsArch: linux/amd64
  Version: 4.9.3

Podman in a container

No

Privileged Or Rootless

Rootless

Upstream Latest Release

Yes

Additional environment details

Additional environment details

Additional information

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

@mbhangui mbhangui added the kind/bug Categorizes issue or PR as related to a bug. label Feb 25, 2024
@edsantiago
Copy link
Collaborator

Context

rhatdan added a commit to rhatdan/podman that referenced this issue Feb 26, 2024
Currently if a user specifies a negative time to stop a container the
code ends up specifying the negative time to time.Duration which treats
it as 0. By settine the default to max.Unint32 we end up with a positive
number which indicates > 68 years which is probably close enough to
infinity for our use case.

Fixes: containers#21811

Signed-off-by: Daniel J Walsh <dwalsh@redhat.com>
rhatdan added a commit to rhatdan/podman that referenced this issue Feb 26, 2024
Currently if a user specifies a negative time to stop a container the
code ends up specifying the negative time to time.Duration which treats
it as 0. By settine the default to max.Unint32 we end up with a positive
number which indicates > 68 years which is probably close enough to
infinity for our use case.

Fixes: containers#21811

Signed-off-by: Daniel J Walsh <dwalsh@redhat.com>
rhatdan added a commit to rhatdan/podman that referenced this issue Feb 26, 2024
Currently if a user specifies a negative time to stop a container the
code ends up specifying the negative time to time.Duration which treats
it as 0. By settine the default to max.Unint32 we end up with a positive
number which indicates > 68 years which is probably close enough to
infinity for our use case.

Fixes: containers#21811

Signed-off-by: Daniel J Walsh <dwalsh@redhat.com>
rhatdan added a commit to rhatdan/podman that referenced this issue Feb 26, 2024
Currently if a user specifies a negative time to stop a container the
code ends up specifying the negative time to time.Duration which treats
it as 0. By settine the default to max.Unint32 we end up with a positive
number which indicates > 68 years which is probably close enough to
infinity for our use case.

Fixes: containers#21811

Signed-off-by: Daniel J Walsh <dwalsh@redhat.com>
rhatdan added a commit to rhatdan/podman that referenced this issue Feb 26, 2024
Currently if a user specifies a negative time to stop a container the
code ends up specifying the negative time to time.Duration which treats
it as 0. By settine the default to max.Unint32 we end up with a positive
number which indicates > 68 years which is probably close enough to
infinity for our use case.

Fixes: containers#21811

Signed-off-by: Daniel J Walsh <dwalsh@redhat.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/bug Categorizes issue or PR as related to a bug.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants