CRIU migration: where are cgroup and lxc ?

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.