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

Avoid sending a signal to the containers during checkpointing #11162

Open
dawei-sdw opened this issue Nov 10, 2024 · 0 comments
Open

Avoid sending a signal to the containers during checkpointing #11162

dawei-sdw opened this issue Nov 10, 2024 · 0 comments
Labels
type: enhancement New feature or request

Comments

@dawei-sdw
Copy link
Contributor

Description

In some scenarios, there are cases where the checkpoint time is very long, exceeding 30 seconds, and possibly even longer. During the checkpoint process, the mutex kernel.extMu is already locked. At this point, if the runsc list command is executed, it will hang because the container.SignalContainer function will attempt to acquire the kernel.extMu mutex. This can lead to a blockage. I believe this blockage situation is inappropriate; it would be better not to send signals to containers that are currently undergoing checkpointing.

Is this feature related to a specific bug?

This is not related to a specific bug

Do you have a specific solution in mind?

I think it would be better to add a flag to avoid sending signals to containers that are currently checkpointing, but I haven't come up with a good solution for it.

@dawei-sdw dawei-sdw added the type: enhancement New feature or request label Nov 10, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type: enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant