[lxc-users] lxc-console produces no output

[Robert Pendell]

On Fri, May 9, 2014 at 10:12 AM, CDR <venefax at gmail.com> wrote:
> I detected an issue with all Fedora 20 containers that may benefit
> from --nohangup workaround
> If I start the container without the "-d" flag, then I cannot enter
> the container via the console, later.
> If I start the container without the "-d" flag, it works, bu then I
> cannot get out.
>
> So how do I try this workaround? If you give me precise instructions I
> will try it.
> Note: I have containers of 3 types, Debian, SLES and Fedora, only
> Fedora has the issue.
>
> Philip

At this point it is really only a workaround.  Looking in the thread
that Dwight mentioned it seems that it is/was being discussed so I can
only hope we get a proper solution.  I think it does have its own
security risks...

For Fedora you would need to find where it calls getty or mingetty and
add the --nohangup option to it.  I don't know that though as I don't
use Fedora at all.

>
> On Fri, May 9, 2014 at 9:56 AM, Dwight Engen <dwight.engen at oracle.com> wrote:
>> On Fri, 9 May 2014 00:18:13 -0400
>> Robert Pendell <shinji at elite-systems.org> wrote:
>>
>>> On Fri, May 9, 2014 at 12:12 AM, Robert Pendell
>>> <shinji at elite-systems.org> wrote:
>>> > On Thu, May 8, 2014 at 10:56 PM, Serge Hallyn
>>> > <serge.hallyn at ubuntu.com> wrote:
>>> >> Quoting Robert Pendell (shinji at elite-systems.org):
>>> >>> OS: Ubuntu 14.04 LTS x86_64
>>> >>> Kernel: Host-Supplied 3.14.1
>>> >>> Provider: Linode
>>> >>> Host Virtualization: Xen Paravirtualized
>>> >>> LXC Version: 1.0.3-0ubuntu3
>>> >>> Guest: CentOS 6 i386
>>> >>>
>>> >>> I know I've seen this issue crop up before however I don't know
>>> >>> how it has been fixed and the solution may vary.
>>> >>>
>>> >>> I'm using a standard Centos template created using the download
>>> >>> type. It is running in unprivileged mode and for some reason
>>> >>> lxc-console isn't producing any output when I attempt to connect
>>> >>> to it.
>>> >>>
>>> >>> Here is what I get:
>>> >>> shinji at icarus:~$ sudo lxc-console -n gateone
>>> >>>
>>> >>> Connected to tty 1
>>> >>> Type <Ctrl+a q> to exit the console, <Ctrl+a Ctrl+a> to enter
>>> >>> Ctrl+a itself
>>> >>
>>> >> Before you run lxc-console, find the host pid of the mingetty on
>>> >> pts/1, and strace -f -p that one.
>>> >>
>>> >
>>> > Heh... I tried and it keeps telling me the process id doesn't exist
>>> > then I noticed that the pid is changing so I went into the guest and
>>> > looked at the messages log and it is being spammed with this...
>>> >
>>> > May  8 23:54:17 localhost init: tty (/dev/tty1) main process (2335)
>>> > terminated with status 1
>>> > May  8 23:54:17 localhost init: tty (/dev/tty1) main process ended,
>>> > respawning May  8 23:54:17 localhost /sbin/mingetty[2348]: tty1:
>>> > vhangup() failed
>>> >
>>> > *a few minutes later*
>>> > Found the fix.  This might have to go into the prep script for
>>> > CentOS as it seems to happen for others as well.  It seems the
>>> > folks working on the Oracle image figured this out.
>>> >
>>> > https://github.com/lxc/lxc/blob/master/templates/lxc-oracle.in
>>> > Line 368 comments about how vhangup fails with userns.  It probably
>>> > is related to unprivileged containers only although I have not
>>> > checked with privileged so don't quote me on that last bit.  All I
>>> > know is it fixed the issue for me.  Others may gain usefulness in
>>> > this.
>>> >
>>> > Basically I edited the /etc/init/tty.conf script and added
>>> > --nohangup to the mingetty exec command in the script.
>>> >
>>> > It became this: exec /sbin/mingetty $TTY --nohangup
>>> >
>>> > This will propagate to /dev/console as well due to the way that it
>>> > is being created during boot (it calls the tty init using
>>> > TTY=console as a parameter).
>>>
>>> Adding to my last message:
>>> https://github.com/lxc/lxc/commit/2e83f7201c5d402478b9849f0a85c62d5b9f1589
>>> "This is needed when using the user namespace since the kernel check
>>> does not allow user_ns root to successfully call vhangup(2), and
>>> mingetty will quit in this case."
>>>
>>> So it does appear to only affect unprivileged containers.
>>
>> Hi Robert, yes its only when using user_ns. I added this as a
>> workaround because we never did figure out vhangup in a user_ns. See
>> http://comments.gmane.org/gmane.linux.kernel.containers.lxc.devel/2632
>> for the original discussion.
>>