Greg Kurz [gkurz@xxxxxxxxxx] wrote:
| On Tue, 2010-09-07 at 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
| > either
| > 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 ?
| >
|
| To be more accurate, this issue is about fd leaking from a parent
| container to its descendants. The fd numbers may be anything else than
| 0,1 or 2 and the underlying files may be regular files, pipes,
| sockets... For example, in the HPC world, stdio are often sockets
| inheritated from a rshd like daemon.
I agree that fd substitution is the right way to go.
However, Matt Helsley and I were discussing this and wondered if we should
ignore the redirection and expect to user to specify it during restart.
i.e if container was created like this:
lxc-execute -name foo -- /path/to/app > /tmp/xyz.out 2>&1
and checkpointed, can we expect the user to restart it like this ?
lxc-restart --name foo --statefile ckpt.img >> /tmp/xyz.out
i.e user has to redo the redirection or the output would go to stdout.
Doing this would somehow seem to match a (bogus container) like:
lxc-execute --name foo -- /path/to/app | sort
If this container is checkpointed/restarted, we can't really redirect
the output of the app to 'sort' right ? So expecting the user to
redo the redirection on restart would treat both redirections ('>'
and '|') in a consistent way ?
Sukadev
_______________________________________________
Containers mailing list
Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linux-foundation.org/mailman/listinfo/containers
