You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
The text was updated successfully, but these errors were encountered: