On Tue, 6 May 2014 11:27:47 +0100 "Daniel P. Berrange" <berrange@xxxxxxxxxx> 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 -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list