On Tue, 6 May 2014 11:27:47 +0100
"Daniel P. Berrange" <berrange(a)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