This may not be necessary after all. Looks like there's a way to modify the getty@.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@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/lxc-devel -- Michael H. Warfield (AI4NB) | (770) 985-6132 | m...@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!
signature.asc
Description: This is a digitally signed message part
------------------------------------------------------------------------------ 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
