[lxc-devel] [PATCH 0/5] Signal stuff v2 and some documentation
Ferenc Wagner
wferi at niif.hu
Wed Jun 16 14:53:12 UTC 2010
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.
More information about the lxc-devel
mailing list