lxc and consoles and unix98 ptys (and c/r)

lxc and consoles and unix98 ptys (and c/r)

[Serge E. Hallyn]

Hi Daniel,

I know you've thought the whole console situation through
a great deal - and I haven't - so plz set me straight as
needed.

liblxc supports 'lxc.pts', which tells it to mount a fresh
/dev/pts.  However, it does this very late in the container
startup, and does not appear to support either lxc.tty consoles
or the 'main' console being in that ptsns.

When I want to checkpoint and restart something which writes
to a container in a hand-built container, what I generally do
is start sshd and screen -dm in the container, ssh in,
screen -r, start my job, detach and logout, then do my
freeze/checkpoint/restart, and then i can ssh back in and
screen -r.

That's obviously less than ideal :)  I'd like to be able to
checkpoint lightweight containers by doing

	lxc-execute -n serge -- myscript
or maybe
	lxc-start -d -n serge -- myscript

and have the container init's fd 0-2 be /dev/pts/0 in the
container's devpts mount.

For that to work, lxc-execute would have to mount its new
devpts instance, then open /dev/pts/0, and start up a proxy
to ferry the console info back and forth.  I thought in the
past you'd talked about that, but I can't recall whether you
said you wanted to do it, or that you thought it was too
heavyweight :)

Have you had any such thing in mind?

The related feature of course woudl be for lxc-start with
lxc.tty=4 to first mount a new devpts instance, then run
getty on /dev/pts/[0-4] and let lxc-console attach to
those.

thanks,
-serge

Re: lxc and consoles and unix98 ptys (and c/r)

[Daniel Lezcano]

Serge E. Hallyn wrote:
> Hi Daniel,

Hi Serge,

> I know you've thought the whole console situation through
> a great deal - and I haven't - so plz set me straight as
> needed.
> 
> liblxc supports 'lxc.pts', which tells it to mount a fresh
> /dev/pts.  However, it does this very late in the container
> startup, and does not appear to support either lxc.tty consoles
> or the 'main' console being in that ptsns.

maybe I am misunderstanding but I think you should look at the 
'lxc_create_console' and the 'setup_console' functions, that will show 
why new pts instance and console / tty are not correlated.

> When I want to checkpoint and restart something which writes
> to a container in a hand-built container, what I generally do
> is start sshd and screen -dm in the container, ssh in,
> screen -r, start my job, detach and logout, then do my
> freeze/checkpoint/restart, and then i can ssh back in and
> screen -r.
> 
> That's obviously less than ideal :)  I'd like to be able to
> checkpoint lightweight containers by doing
> 
> 	lxc-execute -n serge -- myscript
> or maybe
> 	lxc-start -d -n serge -- myscript
> 
> and have the container init's fd 0-2 be /dev/pts/0 in the
> container's devpts mount.
> 
> For that to work, lxc-execute would have to mount its new
> devpts instance, then open /dev/pts/0, and start up a proxy
> to ferry the console info back and forth.  I thought in the
> past you'd talked about that, but I can't recall whether you
> said you wanted to do it, or that you thought it was too
> heavyweight :)

lxc-start which runs system container does that if it is specified in 
the configuration.

> Have you had any such thing in mind?

lxc-execute is for running application containers and the *stdio* are 
inherited in the container.

I suppose it may be possible to generalize the console, the ttys and the 
stdio.

> The related feature of course woudl be for lxc-start with
> lxc.tty=4 to first mount a new devpts instance, then run
> getty on /dev/pts/[0-4] and let lxc-console attach to
> those.

I am a bit lost, what do you want to do ? Do you plan to make tty, 
console and stdio using the same mechanism and get rid of the actual 
bind mount of <rootfs>/dev/console|tty ?

Can you elaborate a bit and send a draft-patch to illustrate your idea ?

Thanks
   -- Daniel

Re: lxc and consoles and unix98 ptys (and c/r)

[Serge E. Hallyn]

Quoting Daniel Lezcano (dlezcano-NmTC/0ZBporQT0dZR+AlfA@public.gmane.org):
> Serge E. Hallyn wrote:
> >Hi Daniel,
> 
> Hi Serge,
> 
> >I know you've thought the whole console situation through
> >a great deal - and I haven't - so plz set me straight as
> >needed.
> >
> >liblxc supports 'lxc.pts', which tells it to mount a fresh
> >/dev/pts.  However, it does this very late in the container
> >startup, and does not appear to support either lxc.tty consoles
> >or the 'main' console being in that ptsns.
> 
> maybe I am misunderstanding but I think you should look at the
> 'lxc_create_console' and the 'setup_console' functions, that will
> show why new pts instance and console / tty are not correlated.

Ok thanks, Daniel, I'll look at lxc/src/lxc some more until I can
be more specific.

> >When I want to checkpoint and restart something which writes
> >to a container in a hand-built container, what I generally do
> >is start sshd and screen -dm in the container, ssh in,
> >screen -r, start my job, detach and logout, then do my
> >freeze/checkpoint/restart, and then i can ssh back in and
> >screen -r.
> >
> >That's obviously less than ideal :)  I'd like to be able to
> >checkpoint lightweight containers by doing
> >
> >	lxc-execute -n serge -- myscript
> >or maybe
> >	lxc-start -d -n serge -- myscript
> >
> >and have the container init's fd 0-2 be /dev/pts/0 in the
> >container's devpts mount.
> >
> >For that to work, lxc-execute would have to mount its new
> >devpts instance, then open /dev/pts/0, and start up a proxy
> >to ferry the console info back and forth.  I thought in the
> >past you'd talked about that, but I can't recall whether you
> >said you wanted to do it, or that you thought it was too
> >heavyweight :)
> 
> lxc-start which runs system container does that if it is specified
> in the configuration.
> 
> >Have you had any such thing in mind?
> 
> lxc-execute is for running application containers and the *stdio*
> are inherited in the container.

I *guess* what I'd like is a way to do an lxc-execute -d, where I
can then re-connect to the console with lxc-console.  So I don't
want a system container (no /sbin/init), I just want the application
to be detached from my console, running in /dev/pts/0 in its own
devpts mount.

> I suppose it may be possible to generalize the console, the ttys and
> the stdio.
> 
> >The related feature of course woudl be for lxc-start with
> >lxc.tty=4 to first mount a new devpts instance, then run
> >getty on /dev/pts/[0-4] and let lxc-console attach to
> >those.
> 
> I am a bit lost, what do you want to do ? Do you plan to make tty,
> console and stdio using the same mechanism and get rid of the actual
> bind mount of <rootfs>/dev/console|tty ?

Well to focus on the specific problem I'm trying to solve: I want to be
able to checkpoint and restart an application container started with
lxc-execute.  In order to be able to do that without doing fancy
plugging of stdin/out/err of the container init at restart, we would
need container init's console to be isolated in the container.  That's
weird of course since we must connect it to the caller's console
somehow.

> Can you elaborate a bit and send a draft-patch to illustrate your idea ?

Will keep thinking for awhile and hopefully come back with something.

thanks,
-serge