On Tue, 6 May 2014 11:27:47 +0100 "Daniel P. Berrange" <berrange@redhat.com> wrote:
On Mon, May 05, 2014 at 11:14:18AM -0400, Dwight Engen wrote:
When a console is configured, /dev/console and /dev/tty1 are created as symlinks to the same underlying pts. This causes problems since a separate getty will be spawned for /dev/console and /dev/tty1, but they are each controlling the same device.
That is simply a bug in the OS setup IMHO.
I agree it doesn't make sense when /dev/console is 5:1 and is tracking the current vt via tty0, but in a container situation where its just another pty spawning a getty on it makes sense. I ran into this because I was testing the compatibility of the containers setup by lxc templates with libvirt-lxc, and most of them set up a getty on /dev/console since it's a separate pty. I was hoping to avoid this environmental difference in the way the container is setup between lxc and libvirt-lxc so that container's contents wouldn't have to know about it.
FYI systemd specified that the 'container_ttys' env variable should be set to indicate which devices a gettty should be spawned on and libvirt now sets that. We intentionally exclude tty1 from the container_ttys env var so we don't get the double-getty with any systemd enabled OS.
IMHO even non-systemd OS could read that env var to decide where to spawn getttys
I noticed that the ubuntu upstart job checks for container=lxc before spawning a getty on the console, so it seems like that may be the best approach since it should also work in a non-container case as well. Thanks for the feedback.
See also this doc:
http://www.freedesktop.org/wiki/Software/systemd/ContainerInterface/
This patch makes it so that /dev/console is the sole symlink to the first console, /dev/tty1 to the second, /dev/tty2 to the third and so on.
This is a backwards-incompatible change that is likely to break existing deployments I'm afraid, so we can't do that IMHO.
Regards, Daniel