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
I am experimenting with gvisor's save/restore functionality to decide whether to build atop it. I immediately hit a stumbling block in which restore fails, without an apparent workaround.
If you exec bash, checkpoint, then restore, the restore fails due to FD issues.
I would hope that it would successfully restore, and close the FDs associated with the exec'd bash process that could not be restored. Or that there is some path to bringing the container back up, even if it is in a slightly broken state. (Shortcomings can be documented, worked around, built around; simple failure to restore cannot.)
(I am also left wondering what other surprises might be in store for me, given that I hit this one almost immediately, i.e. #3281)
Thanks!
Steps to reproduce
Terminal 1:
runsc --platform=systrap create x
runsc start x
Terminal 2:
runsc exec x bash
Terminal 1:
runsc checkpoint -image-path=/tmp/x x
runsc delete x
runsc --platform=systrap create x
runsc restore -image-path=/tmp/x x
Yeah checkpointing a container which has live exec sessions is not supported, since we can not re-establish such exec sessions on restore. IIUC, your suggestion is that we silently kill the exec session on restore and clean up all its resources?
Then checkpoint and restore. The checkpoint and restore succeed. But the detached processes show up in ps as kernel processes, but are not actually executing.
# runsc exec x ps
PID USER TIME COMMAND
1 root 0:00 sleep infinity
4 root 0:00 [dtach]
5 root 0:00 [watch]
27 root 0:00 ps
Description
I am experimenting with gvisor's save/restore functionality to decide whether to build atop it. I immediately hit a stumbling block in which restore fails, without an apparent workaround.
If you exec bash, checkpoint, then restore, the restore fails due to FD issues.
I would hope that it would successfully restore, and close the FDs associated with the exec'd bash process that could not be restored. Or that there is some path to bringing the container back up, even if it is in a slightly broken state. (Shortcomings can be documented, worked around, built around; simple failure to restore cannot.)
(I am also left wondering what other surprises might be in store for me, given that I hit this one almost immediately, i.e. #3281)
Thanks!
Steps to reproduce
Terminal 1:
Terminal 2:
runsc exec x bash
Terminal 1:
This results in this failure:
The container is pretty vanilla alpine, running
sleep infinity
.runsc version
# runsc -version runsc version release-20250127.0 spec: 1.1.0-rc.1
uname
The text was updated successfully, but these errors were encountered: