[CRIU] [PATCH 1/2] finalize cgroups correctly

Pavel Emelyanov xemul at parallels.com
Sat Mar 21 13:26:27 PDT 2015


On 03/20/2015 10:38 PM, Saied Kazemi wrote:
> Hi Tycho,
> 
> Yes, if we move the image directory outside the container's root, cgyard will not show 
> up in the restored process.  But we need to understand why it doesn't work when the image
> directory is in the container's root.  One thing I noticed is that rmdir(cg_yard) in
> fini_cgroup() fails with a device busy error.

That's (probably) because of the directory is busy with another mountpoint that
got "cloned" into the restored tasks' mount namespace. The cgyard is created in
crtools_prepare_shared() which is called before root task fork, then root task
calls restore_task_mnt_ns(), which ends up with call to unshare(CLONE_NEWNS) and 
then to pivot_root(). The former clones cgyard.

In kernel 3.17 there appeared a commit 8ed936b5 which causes rmdir() to detach
_all_ mountpoints from dentry that live in another mount namespaces. What is
the kernel version at your box?

> I added code to close all service descriptors, close log file, change dir to "/" but it didn't help.
> 
> If somewhere in container's root is not a valid destination for image directory, CRIU 
> should print an error and exit.

Yes, I agree with that, but given two paths its ... extremely hard to find out
whether one of them can be accessed from another. From my understanding the best
we can do is check the issubpath() of image dir (and working dir) vs root and
exit. But I'd say it would be just a sanity check, in more complicated VFS trees
paths may not be subpaths as strings, but be such as paths :)

> Pavel, do you have an ideas?
> 
> --Saied

Thanks,
Pavel



More information about the CRIU mailing list