Purpose:
If we get rid of cgroup and lxc when we do dump through criu, it is good for us to make migration successfully
LXC:
CRIU itself doesn’t dump lxc(container) unless using lxc-checkpoint tool. So by default, lxc is not considered by CRIU.
Cgroups:
If we unload or don’t use cgroup functionality, a process won’t have information about cgroup. So when we do checkpoint in bash environment, the checkpoint image file cgroup.img should be empty. It is true, in fact.
But when we do dump in ssh environment, and the checkpointed process is running in bash, cgroup.img is not empty, it has the information about bash in which the checkpointed process is running.
And here is the information about the bash:
2:name=systemd:/user/1000.user/c2.session
while cat /proc/self/cgroup in the ssh in which criu is running
2:name=systemd:/user/1000.user/22.session
So it is strange, we don’t enable cgroup functionality, why the cgroup.img is not empty? Just because we use ciru in ssh environment?
Yes.
First, let’s think so. If we run criu and the checkpointed process both in bash, we should use –shell-job to ignore the “leaked” session leader which is bash. So we can do checkpoint/restore successfully.
But now criu is in ssh, while the checkpointed process is in bash. Just like:
If they are both in bash, we can think that they belongs to one common user, so criu can ignore the information about the user, such as session id. But now one is in bash, while the other is in ssh, just equivalent to two different users. So criu which is in ssh shouldn’t ignore where the checkpointed process comes from. So criu will write down the bash information in cgroup.img.
( 譯文：如果都在bash中，可以理解爲從屬於同一個用戶，所以可以忽略這個用戶的標識信息。但現在一個在bash，而另一個在ssh，相當於兩個不同用戶，位於ssh的criu在checkpoint時就要點出被checkpoint的process來自何方，這也就是cgroup.img出現bash信息的原因。)
Conclusion:
On one server (called bug03), we run criu and the checkpointed process both in bash environment. And then lxc and crgoup won’t be considered. And the cgroup.img is empty, which means that criu ignores the information about bash session. In one word, the checkpoint is pure.
In such theory, the miration from bug03 to bug02(the destination node) will succeed, even though the bash session information between bug02 and bug03 is different.
Verification:
My lap has seven tty, different tty has different bash session id. I do the checkpoint in tty7(i.e. X Window), the session id is :
2:name=systemd:/user/1000.user/c2.session
And then I do the restore in another tty: tty2, its session id is :
2:name=systemd:/user/1000.user/c5.session
Even though the two tty have different bash session id, but tty2 can restore successfully.
Furthermore, I build a new user named tomk, and when I login it, its bash session id is :
2:name=systemd:/user/1002.user/c7.session
which has different user id and session id from tty7(X Window).
And in tty2:tomk, it can also restore successfully.
So we do dump on bug02 in bash environment, and on bug03. we can restore successfully.
Truth:
For the simple program: test_mm (which starts two threads, and only printf). I do dump on bug02, then scp checkpoint.img from bug02 to bug03, and then do restore on bug03. It succeeds finally.