On Sun, 2013-05-19 at 00:02 +0530, Shridhar Daithankar wrote: > On Saturday, May 18, 2013 09:58:26 AM Michael H. Warfield wrote: > > On Sat, 2013-05-18 at 19:02 +0530, Ajith Adapa wrote: > > > Then I have started the container using below command and tried to > > > connect to its shell using lxc-console command but I ended up with > > > below message. Ideally I should see a prompt but its just hangs down > > > there. <Ctl+a q> works and nothing else. > > > > > > [root@ipiblr ~]# lxc-start -n TEST -d > > > [root@ipiblr ~]# lxc-console -n TEST > > > > > > Type <Ctrl+a q> to exit the console, <Ctrl+a Ctrl+a> to enter Ctrl+a > > > itself > > > > Oh, crap... I keep forgetting about that (because I don't use it). > > That needs to be noted somewhere in the documentation. > > > > That's yet another BAD decision on the part of the systemd crowd, > > lxc-console is probably not going to work, at least for the time being. > > They (systemd) intentionally, with documented malice a forethought, > > disable gettys on the vtys in the container if systemd detects that it's > > in a container. However, /dev/console in the container is still active > > and is connected to lxc-start and I'm able to log in there but I have > > never gotten lxc-console to work with a systemd container and I don't > > know of anything I can do about it. You would need some way to force > > the container to start gettys on the vtys. > > > > Maybe, if I (or someone else) can figure out a way to do that (force the > > gettys to start on the vtys), it could be integrated into the Fedora > > template. My patches for the autodev stuff (plus other stuff) have now > > been accepted and applied by Serge, so that's done. Maybe I can look > > deeper into this morass now.
> First of all, let me say thank you for your concise message upthread. It > renewed my interest in lxc and I managed to get a working container for the > first time. I will post a detailed HOWTO shortly. > I ran into the same lxc-console issue and managed to solve it by commenting > out ConditionPathExists line in > /etc/systemd/system/getty.target.wants/getty\@tty1.service > first I had to start the container in foreground, login, comment out > aforementioned line and restart it in daemon mode. After that lxc-console > worked. > If I changed the systemd unit from the chroot itself, it didn't reflect > somehow. Also the line referred to /dev/tty0 but only /dev/tty and /dev/tty1 > were available in the container. > I don't understand systemd enough to comment on the reasons of it working or > not-working. I just experimented around to get a working tty. Oh, I understand why it's working and that's VERY interesting. I hadn't dug into that realm of the systemd files as yet. They're using the mere existence of /dev/tty0 as a logic switch to determine if they are going to start a getty on %I (/dev/tty1 in this case). Which is yet another case of them burying a magic cookie switch in the logic. They conditionalize it on a hard coded /dev/tty0 but then start a getty "/sbin/agetty --noclear %I 38400". the %I is the unit name. Cute. Cheeky bastards. So, it basically means that if we create a tty0 under autodev, that should then enable any listed vty consoles we set up using systemd links. That could be a key to making that work without modifying files in the container but would require a (relatively minor but non trivial) change to the lxc source code, as opposed to merely a template. I'll run this up the flagpole on the -devel list and with Serge and get their opinions. This is doable. I think I'll try this out in my sources first and then post a request for comments over on -devel. The problem is in the routine "setup_tty" in conf.c that's going to need some massaging to make it 0 based instead of 1 based and adjust for the additional tty count. :-/ > My environment is arch linux and the details are as follows. > kernel : 3.9.2-1 > systemd : 204-1 > lxc : 1:0.9.0-2 > > HTH > > -- > Regards > Shridhar > -- 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-users mailing list Lxc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-users
