mirror of
https://github.com/checkpoint-restore/criu
synced 2025-08-31 06:15:24 +00:00
e36dbef13d9831e6ca0e1fded944f62e5b5f991f
If criu restore failed, criu should wait all processes because they hold files, namespaces and other stuff that caller might want to have released (in our case it was ploop device). Here we do this only for cases when processes are restored in a pid namespace. We'd like to do the same for non-ns case, but there's no simple way to wait for a bunch of unconnected processes. Another good side effect is that "Restoring FAILED." will be printed at the end of the log (now after we kill init tasks still have time to do smth and write log messages). Cc: Nikita Spiridonov <nspiridonov@odin.com> Reported-by: Nikita Spiridonov <nspiridonov@odin.com> Signed-off-by: Andrew Vagin <avagin@openvz.org> Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
CRIU (Checkpoint and Restore in Userspace)
An utility to checkpoint/restore tasks. Using this tool, you can freeze a running application (or part of it) and checkpoint it to a hard drive as a collection of files. You can then use the files to restore and run the application from the point it was frozen at. The distinctive feature of the CRIU project is that it is mainly implemented in user space.
The project home is at http://criu.org.
Pages worth starting with are:
- Kernel configuration, compilation, etc
- A simple example of usage
- More sophisticated example with graphical app
How to contribute
- How to submit patches;
- Send all bug reports to mailing list;
- Spread the word about CRIU in social networks;
Description
Languages
C
86%
Python
6.1%
Java
2.6%
Shell
2.6%
Makefile
2%
Other
0.7%