Linux Container Development
 help / color / mirror / Atom feed
From: Greg Kurz <gkurz-NmTC/0ZBporQT0dZR+AlfA@public.gmane.org>
To: Sukadev Bhattiprolu
	<sukadev-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
Cc: Dan Smith <danms-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>,
	Nathan Lynch <nathanl-V7BBcbaFuwjMbYB6QlFGEg@public.gmane.org>,
	Containers
	<containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org>
Subject: Re: C/R and stdio redirection
Date: Wed, 08 Sep 2010 11:44:52 +0200	[thread overview]
Message-ID: <1283939092.32527.67.camel@bahia> (raw)
In-Reply-To: <20100907200326.GA22256-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>

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.

-- 
Gregory Kurz                                     gkurz-NmTC/0ZBporQT0dZR+AlfA@public.gmane.org
Software Engineer @ IBM/Meiosys                  http://www.ibm.com
Tel +33 (0)534 638 479                           Fax +33 (0)561 400 420

"Anarchy is about taking complete responsibility for yourself."
        Alan Moore.

  parent reply	other threads:[~2010-09-08  9:44 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-09-07 20:03 C/R and stdio redirection Sukadev Bhattiprolu
     [not found] ` <20100907200326.GA22256-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
2010-09-08  8:41   ` Louis Rilling
     [not found]     ` <20100908084152.GC4812-Hu8+6S1rdjywhHL9vcZdMVaTQe2KTcn/@public.gmane.org>
2010-09-08 10:00       ` Greg Kurz
2010-09-08 10:21         ` Louis Rilling
2010-09-08  9:44   ` Greg Kurz [this message]
2010-10-06  5:50     ` Sukadev Bhattiprolu
     [not found]       ` <20101006055017.GA22969-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
2010-10-06  9:58         ` Louis Rilling
     [not found]           ` <20101006095835.GC30415-Hu8+6S1rdjywhHL9vcZdMVaTQe2KTcn/@public.gmane.org>
2010-10-06 13:43             ` Greg Kurz

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1283939092.32527.67.camel@bahia \
    --to=gkurz-nmtc/0zbporqt0dzr+alfa@public.gmane.org \
    --cc=containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org \
    --cc=danms-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org \
    --cc=nathanl-V7BBcbaFuwjMbYB6QlFGEg@public.gmane.org \
    --cc=sukadev-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox