[lxc-devel] [RFC] Systemd, lxc-console, and ttys!

[Michael H. Warfield]

This may not be necessary after all.  Looks like there's a way to modify
the getty at .service configuration and override the default to get systemd
to fire up agetty on the containers ttys that could be implemented in
the lxc-fedora template and others.  I'll send a patch in for that
approach shortly.

Regards,
Mike

On Sat, 2013-05-18 at 17:03 -0400, Michael H. Warfield wrote:
> All,
> 
> Over on the -users list (if you haven't been tuned into the thread on
> creating a Fedora container) we've been boiling out another systemd
> gotcha.
> 
> Basically, lxc-console does not work with systemd because systemd does
> not start containers on /dev/ttyN.  Their documentation indicates that
> it's because it's in a container.  Someone has uncovered the logic
> (magic cookie) that contradicts that.  The logic switch is on the
> existence of /dev/tty0 (the magic cookie).  If it exists, systemd will
> start gettys on /dev/ttyN (only /dev/tty1 by default) and lxc-console
> will work.  If it doesn't exist, systemd will not start gettys for the
> vtys and lxc-console will not work.
> 
> Obvious solution...  Create /dev/tty0 and lxc-console will work.
> Looking at the code, it looks like it's rife with side effects guarded
> by gremlins there in conf.c.  We would need to modify "lxc_create_tty"
> and "setup_tty" in conf.c to make them 0 based, instead of 1 based, and
> adjust for an additional tty (lxc.tty + 1).  That SHOULD be straight
> forward.  But...  Shifting the base of the lxc_tty_info structure could
> have unforeseen (on my part) side effects which could impact LOTS of
> things.
> 
> Maybe it would be easier to "hack it" and create something entirely
> separate to just create the special case of /dev/tty0.  I don't know.
> 
> So that's what we have to do (AFAICT) to make lxc-console play nicey
> nicey with systemd and that's what it appears (to me) that we need to do
> it.  But it appears that "here there be dragons".  I can do some of the
> coding but I need to understand some of the implications before I make
> things fall down go boom.
> 
> Regards,
> Mike
> ------------------------------------------------------------------------------
> AlienVault Unified Security Management (USM) platform delivers complete
> security visibility with the essential security capabilities. Easily and
> efficiently configure, manage, and operate all of your security controls
> from a single console and one unified framework. Download a free trial.
> http://p.sf.net/sfu/alienvault_d2d
> _______________________________________________ Lxc-devel mailing list Lxc-devel at lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel

-- 
Michael H. Warfield (AI4NB) | (770) 985-6132 |  mhw at WittsEnd.com
   /\/\|=mhw=|\/\/          | (678) 463-0932 |  http://www.wittsend.com/mhw/
   NIC whois: MHW9          | An optimist believes we live in the best of all
 PGP Key: 0x674627FF        | possible worlds.  A pessimist is sure of it!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 482 bytes
Desc: This is a digitally signed message part
URL: <http://lists.linuxcontainers.org/pipermail/lxc-devel/attachments/20130519/22fdc334/attachment.pgp>