[lxc-devel] [PATCH v2] fix console stdin,stdout,stderr fds

[Dwight Engen]

On Mon, 10 Mar 2014 12:39:55 -0500
Serge Hallyn <serge.hallyn at ubuntu.com> wrote:

> Quoting Dwight Engen (dwight.engen at oracle.com):
> > On Fri, 7 Mar 2014 17:58:07 -0600
> > Serge Hallyn <serge.hallyn at ubuntu.com> wrote:
> > 
> > > Quoting Dwight Engen (dwight.engen at oracle.com):
> > > > On Fri, 7 Mar 2014 17:01:17 -0600
> > > > Serge Hallyn <serge.hallyn at ubuntu.com> wrote:
> > > > 
> > > > > Quoting Dwight Engen (dwight.engen at oracle.com):
> > > > > > +	if (lxc_console_set_stdfds(handler) < 0)
> > > > > > +		goto out_warn_father;
> > > > > > +
> > > > > >  	close(handler->sigfd);
> > > > > >  
> > > > > > +	if (lxc_check_inherited(handler->conf))
> > > > > > +		return -1;
> > > > > > +
> > > > > 
> > > > > Hi,
> > > > > 
> > > > > so the reason why the lxc_check_inherited() was where it
> > > > > was, was because at this point we've called tmp_proc_umount().
> > > > > So in some cases /proc won't be mounted, and
> > > > > lxc_check_inherited() finds the fds to close under /proc
> > > > 
> > > > Ahh okay that makes sense, good catch. So it seems like I should
> > > > leave lxc_check_inherited() where it was and then just put the
> > > > call to lxc_console_set_stdfds() just before it since it looks
> > > > like check_inherited() will leave 0,1,2 alone and close the
> > > > original fds. Does that sound reasonable?
> > > 
> > > Yeah, that sounds good.
> > > 
> > > thanks,
> > > -serge
> > 
> > Hi Serge, I noticed that just doing the above means that
> > stdin,out,err will be changed for the start hook, is that going to
> > be a problem? If so, then maybe what we can do is arrange for
> > check_inherited() ignore the console pty's as well and do the
> > set_stdfds() after the hook runs?
> 
> Since the start hook runs out of the container's filesystem, I think
> it is fine to have them run under the container's pty.  (Keeping in
> mind that the stdout is dup'd to a pipe, while stdin and stderr are
> unchanged)
> 
> Does that make sense?

Yeah I think so, as long as we're not trying to support interactive
hook scripts (which I don't think we should!). ie. the following hook
script would work before this change:

#!/bin/sh
echo "Enter something" >&2
stty sane
read something
echo "Got something $something" >&2

but won't afterwards for the read part since lxc isn't yet in the
mainloop forwarding the pty data so the read will be stuck. The echo
outputting to stderr will buffer up in the pty and eventually come out
so that side is okay as long as not too much data gets put in the pty.

Just wanted to point out this difference, but otherwise I think the v3
patch should be okay :)