-
Notifications
You must be signed in to change notification settings - Fork 2.3k
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
--sdnotify=healthy
leads to a panic when a rootless container is started
#22651
Labels
kind/bug
Categorizes issue or PR as related to a bug.
Comments
we are doing the unlock from a different thread (since the code runs from a goroutine) so the LockOSThread in LockSemaphore has no effect. The call should be moved to the same thread |
giuseppe
added a commit
to giuseppe/libpod
that referenced
this issue
May 9, 2024
wait for the healthy status on the thread where the container lock is held. Otherwise, if it is performed from a go routine, a different thread is used (since the runtime.LockOSThread() call doesn't have any effect), causing pthread_mutex_unlock() to fail with EPERM. Closes: containers#22651 Signed-off-by: Giuseppe Scrivano <[email protected]>
opened a PR: #22658 |
giuseppe
added a commit
to giuseppe/libpod
that referenced
this issue
May 9, 2024
wait for the healthy status on the thread where the container lock is held. Otherwise, if it is performed from a go routine, a different thread is used (since the runtime.LockOSThread() call doesn't have any effect), causing pthread_mutex_unlock() to fail with EPERM. Closes: containers#22651 Signed-off-by: Giuseppe Scrivano <[email protected]>
giuseppe
added a commit
to giuseppe/libpod
that referenced
this issue
May 9, 2024
wait for the healthy status on the thread where the container lock is held. Otherwise, if it is performed from a go routine, a different thread is used (since the runtime.LockOSThread() call doesn't have any effect), causing pthread_mutex_unlock() to fail with EPERM. Closes: containers#22651 Signed-off-by: Giuseppe Scrivano <[email protected]>
giuseppe
added a commit
to giuseppe/libpod
that referenced
this issue
May 13, 2024
wait for the healthy status on the thread where the container lock is held. Otherwise, if it is performed from a go routine, a different thread is used (since the runtime.LockOSThread() call doesn't have any effect), causing pthread_mutex_unlock() to fail with EPERM. Closes: containers#22651 Signed-off-by: Giuseppe Scrivano <[email protected]>
giuseppe
added a commit
to giuseppe/libpod
that referenced
this issue
May 14, 2024
wait for the healthy status on the thread where the container lock is held. Otherwise, if it is performed from a go routine, a different thread is used (since the runtime.LockOSThread() call doesn't have any effect), causing pthread_mutex_unlock() to fail with EPERM. Closes: containers#22651 Signed-off-by: Giuseppe Scrivano <[email protected]>
giuseppe
added a commit
to giuseppe/libpod
that referenced
this issue
May 14, 2024
wait for the healthy status on the thread where the container lock is held. Otherwise, if it is performed from a go routine, a different thread is used (since the runtime.LockOSThread() call doesn't have any effect), causing pthread_mutex_unlock() to fail with EPERM. Closes: containers#22651 Signed-off-by: Giuseppe Scrivano <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Issue Description
Using
--sdnotify=healthy
to notify systemd when a container is healthy leads to a panic.Steps to reproduce the issue
Run a rootless container as a systemd service with
-sdnotify=healthy
.Describe the results you received
Systemd is not notified and the service start-up times out.
Relevant entries from the journal:
Note: the "Notify sent successfully" in the log refers to the message where the MAINPID was sent.
There should be another another message with the same text when the "READY" message is sent, which does not happen due to the panic.
Describe the results you expected
The goroutine should not panic, wait for the container to be healty and notify systemd.
podman info output
Podman in a container
No
Privileged Or Rootless
Rootless
Upstream Latest Release
Yes
Additional environment details
No response
Additional information
The commit that added this feature is 0cfd127
This is the relevant part (2nd frame of the backtrace above):
The text was updated successfully, but these errors were encountered: