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
API - system service panics if events connection closes #6805
Labels
HTTP API
Bug is in RESTful API
kind/bug
Categorizes issue or PR as related to a bug.
locked - please file new issue/PR
Assist humans wanting to comment on an old issue or PR with locked comments.
Comments
openshift-ci-robot
added
the
kind/bug
Categorizes issue or PR as related to a bug.
label
Jun 28, 2020
I can repro this. @jwhonce ptal |
mheon
added a commit
to mheon/libpod
that referenced
this issue
Jul 1, 2020
We weren't actually halting the goroutine that sent events, so it would continue sending even when the channel closed (the most notable cause being early hangup - e.g. Control-c on a curl session). Use a context to cancel the events goroutine and stop sending events. Fixes containers#6805 Signed-off-by: Matthew Heon <matthew.heon@pm.me>
mheon
added a commit
to mheon/libpod
that referenced
this issue
Jul 1, 2020
We weren't actually halting the goroutine that sent events, so it would continue sending even when the channel closed (the most notable cause being early hangup - e.g. Control-c on a curl session). Use a context to cancel the events goroutine and stop sending events. Fixes containers#6805 Signed-off-by: Matthew Heon <matthew.heon@pm.me>
mheon
added a commit
to mheon/libpod
that referenced
this issue
Jul 2, 2020
We weren't actually halting the goroutine that sent events, so it would continue sending even when the channel closed (the most notable cause being early hangup - e.g. Control-c on a curl session). Use a context to cancel the events goroutine and stop sending events. Fixes containers#6805 Signed-off-by: Matthew Heon <matthew.heon@pm.me>
mheon
added a commit
to mheon/libpod
that referenced
this issue
Jul 2, 2020
We weren't actually halting the goroutine that sent events, so it would continue sending even when the channel closed (the most notable cause being early hangup - e.g. Control-c on a curl session). Use a context to cancel the events goroutine and stop sending events. Fixes containers#6805 Signed-off-by: Matthew Heon <matthew.heon@pm.me>
mheon
added a commit
to mheon/libpod
that referenced
this issue
Jul 6, 2020
We weren't actually halting the goroutine that sent events, so it would continue sending even when the channel closed (the most notable cause being early hangup - e.g. Control-c on a curl session). Use a context to cancel the events goroutine and stop sending events. Fixes containers#6805 Signed-off-by: Matthew Heon <matthew.heon@pm.me>
skorhone
pushed a commit
to skorhone/libpod
that referenced
this issue
Jul 7, 2020
We weren't actually halting the goroutine that sent events, so it would continue sending even when the channel closed (the most notable cause being early hangup - e.g. Control-c on a curl session). Use a context to cancel the events goroutine and stop sending events. Fixes containers#6805 Signed-off-by: Matthew Heon <matthew.heon@pm.me>
github-actions
bot
added
the
locked - please file new issue/PR
Assist humans wanting to comment on an old issue or PR with locked comments.
label
Sep 23, 2023
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Labels
HTTP API
Bug is in RESTful API
kind/bug
Categorizes issue or PR as related to a bug.
locked - please file new issue/PR
Assist humans wanting to comment on an old issue or PR with locked comments.
Is this a BUG REPORT or FEATURE REQUEST? (leave only one on its own line)
/kind bug
Description
The system service command will crash (panic) if the events API was called, and an event is generated after the connection has closed
Steps to reproduce the issue:
podman system service -t 0 tcp:localhost:7555
curl http://localhost:7555/v1.0.0/libpod/events
ctrl-c
or SIGINT the curl commanddo anything to generate an event output (e.g. restart a container)
Describe the results you received:
Describe the results you expected:
continue to run
Additional information you deem important (e.g. issue happens only occasionally):
Output of
podman version
:Output of
podman info --debug
:Package info (e.g. output of
rpm -q podman
orapt list podman
):Additional environment details (AWS, VirtualBox, physical, etc.):
physical machine
The text was updated successfully, but these errors were encountered: