C/R and stdio redirection
Louis.Rilling at kerlabs.com
Wed Sep 8 01:41:52 PDT 2010
On 07/09/10 13:03 -0700, Sukadev Bhattiprolu wrote:
> Suppose we create a container and redirect its stdout/stderr as follows:
> lxc-execute -name foo -- /path/to/app > /tmp/xyz.out 2>&1
> If we attempt to checkpoint the container 'foo', we fail bc one of the
> fds in the application refers to /tmp/xyz.out, which is also in use
> outside the container (specifically sys_checkpoint() fails due to the
> "alien mount ns" check in ckpt_fill_fname()).
> It can be argued, 'foo' is not a strict container (since it shares the
> fd with another container). For this reason, we currently need the
> CHECKPOINT_SUBTREE flag in lxc-checkpoint.
> We initially thought that solving mount-namespaces will solve this, but
> realized that they are both separate problems. Mount-namespace C/R addresses
> preserving the mounts within the container and /tmp/xyz.out is outside
> the container.
> So if an application container needs to redirect stdio as above, we should
> a) disable/ignore the alien-mount-ns check or
> b) try and start the application something like:
> $ cat /tmp/wrapper
> /path/to/app > /tmp/xyz.out 2>&1
> $ lxc-execute --name foo -- /tmp/wrapper
> with the difference being /tmp/xyz.out is now inside the container's /tmp
> filesystem rather than in the parent container.
> Maybe we can go with approach 'a' above only if CHECKPOINT_SUBTREE is also
> set - we had discussed this before and considered it hacky.
> Or are there other solutions to this stdio redirection issue ?
I think that this should be solved by a file substitution facility combined with
an ability to ignore "unsupported files" at checkpoint.
File substitution is the ability to tell sys_restart() to substitute some of
caller's file descriptors to checkpointed file descriptors.
Ignoring "unsupported files" means that the checkpoint could record that a given
file descriptor was shared by some files_struct, but the file descriptor itself
is not checkpointed because of various reasons, like file descriptor outside
the container, unsupported file systems, etc.
Both of those mechanisms have been developed in Kerrighed, and Matthieu (in Cc)
should start a discussion about this in the next weeks.
Dr Louis Rilling Kerlabs
Skype: louis.rilling Batiment Germanium
Phone: (+33|0) 6 80 89 08 23 80 avenue des Buttes de Coesmes
http://www.kerlabs.com/ 35700 Rennes
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 197 bytes
Desc: Digital signature
Url : http://lists.linux-foundation.org/pipermail/containers/attachments/20100908/515d0a43/attachment.pgp
More information about the Containers