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
Labels
kind/bug
Categorizes issue or PR as related to a bug.
Comments
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
Issue Description
The online documentation for podman stop command says
However using -1 as timeout shows overflow or a 64bit unsigned integer and results in an immediate SIGKILL
Steps to reproduce the issue
Steps to reproduce the issue
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
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
The text was updated successfully, but these errors were encountered: