lxc and consoles and unix98 ptys (and c/r)
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
A message that is not in the archive (sent off-list or not yet received): 20100427224855.GA7746-r/[email protected]
Quoted 1 line · Serge E. Hallyn
Hi Daniel,
Hi Serge,
Quoted 8 lines
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.
Quoted 17 lines
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 -- myscriptand have the container init's fd 0-2 be
/dev/pts/0in the container's devpts mount.
Quoted 6 lines
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.
Quoted 1 line
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.
Quoted 4 lines
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
A message that is not in the archive (sent off-list or not yet received): 4BD843F6.9040304-NmTC/[email protected]
Quoted 9 lines · Daniel Lezcano
Quoted 1 line · Serge E. Hallyn
Hi Daniel,
Hi Serge,
Quoted 4 lines
I know you've thought the whole console situation through a great deal - and I haven't - so plz set me straight as needed.
Quoted 8 lines
Quoted 4 lines
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.
Quoted 24 lines
Quoted 17 lines
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 -- myscriptand have the container init's fd 0-2 be
/dev/pts/0in the container's devpts mount.Quoted 6 lines
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 :)
Quoted 7 lines
lxc-start which runs system container does that if it is specified in the configuration.
Quoted 1 line
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.
Quoted 11 lines
I suppose it may be possible to generalize the console, the ttys and the stdio.
Quoted 4 lines
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.
Quoted 1 line
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