Probing C/R

Sometimes CRIU is unable to checkpoint or restore a process for various reasons. This article describes a way to check whether CRIU works or not for a given case.

Rationale

It might be the case that a process can not be dumped at all (see what cannot be checkpointed), or that there are some problems which can be fixed. One way to check if checkpoint/restore will work is to run criu dump with --leave-running on the source system, copy the dump over, then run criu restore on the destination.

The problems with the above approach are:

• If restore succeeds, one will have two sets of same processes running on two machines, which may have disastrous effects;
• A lot of memory is dumped to disk and transferred to the destination system, which is not necessary for a test run.

To solve these, an easier and faster way to test if dump/restore will work, --check-only option was introduced.

Usage

Source system:

# criu dump --check-only -D /tmp/cp -t <PID>
Only checking if requested operation will succeed
...
# rsync -a /tmp/cp dest-system:/tmp

Destination system:

# criu restore -D /tmp/cp
Checking mode enabled
...

Upon restore, CRIU will see that the checkpoint is a check-only one, and will do restore in a check-only mode automatically, so there is no need to supply this option explicitly.

Restore-only

One can use the --check-only switch on a full checkpoint, to see if the restore will succeed, at the same time making sure the process will not start running:

Destination system:

# criu restore --check-only -D /tmp/cp
Only checking if requested operation will succeed
Checking mode enabled
...

Currently only the existing checks (e.g., check binary size) are run in check-only mode, but additional checks could be added, for example:

• checksums of binaries
• checksums of used libraries
• available memory