[libvirt] [PATCH] LXC: don't doubly link /dev/console

[Dwight Engen]

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