atp <andrew.phill...@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. ------------------------------------------------------------------------------ ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo _______________________________________________ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
