[lxc-devel] [PATCH 0/5] Signal stuff v2 and some documentation

[Ferenc Wagner]

atp <Andrew.Phillips at lmax.com> writes:

>>> Interestingly, it stays in S state until
>>> I kill the container.  I'm afraid the console functionality (is there
>>> any documentation for it?) may make lxc-start unsuitable for pushing
>>> into the background. After all, it is an interactive foreground process
>>> in that case, a real proxy towards some getty (if I understand this
>>> console thingie right).  Maybe this should be handled differently to
>>> application containers.  But then I'm not sure how Ctrl-C and similar
>>> should be forwarded to a getty...
>> 
>> argh. yes, chicken-egg problem.
>
> The lxc.console=$(tty) thing was something I was thinking about. 
>
> There are a couple of things I've noticed and was pondering how to fix;
>
> 1) The expectation I have from xen, kvm etc is that you can detach from
> the console like lxc-console allows. i.e. 
> lxc-start -C -n test 
> behaves like
> lxc-start -n test ; lxc-console
>
>  - at the moment you have an interactive foreground process. 

I have the same concern, and feel the need for detaching, too.  The -C
option is your invention, right?  It's indeed similar to xm create -c in
Xen; I've got no experience with KVM.

I agree that either we should copy the existing tools (I can't see any
problem with their approach) or delegate the whole console handling to
the GNU screen terminal multiplexer.  A fairly well-known and effective
utility, it could probably replace lxc-console for tty access, too.
What do you think?  Then lxc-start could simply start a screen session
for each running container, with a buffer for each tty and the console.

> 2) If you have a getty on the console, when you start without -s
> lxc.console=$(tty) it puts the system messages and the getty on the host
> system console. That gets confusing when logging in on a lights out 
> console. 

This sounds rather unfortunate.

> Was this what lxcd was for? 
>
> Should it be that lxc-start always goes into the background, and holds
> onto the console, which you can connect to via lxcd by specifying a flag
> to lxc-console? lxc-start -s lxc.console gets replaced by lxc-start -C
> which is equivalent to lxc-start ; lxc-console 

So lxcd seems like a detached screen session to me.

Based on the above, I agree that lxc-start should unconditionally go
into the background, but optionally leave the application it runs in the
foreground.  Maybe it could notice that the container dropped all
references to its inputs/outputs, and then background it as well, but
I'm not sure if it's actually possible.  It's probably better to leave
that to a command line switch like -c above.

One more thing which may or may not matter for us: /dev/console is never
a controlling terminal under Linux.
-- 
Thanks,
Feri.