Hi folks,

by an recent post @users list I learned, I'm not the only one who
likes to catch the console at VE bootup. There are several ways
to work around (within the VE), but this actually doesn't *solve*
the problem.

No I'd like to request an feature for catching the console.
IMHO, it's enough to have an option to vzctl start, which tells
it to not to detach and bring the VE's console to the current tty.

How could this be done ?


cu
-- 
---------------------------------------------------------------------
 Enrico Weigelt    ==   metux IT service - http://www.metux.de/
---------------------------------------------------------------------
 Please visit the OpenSource QM Taskforce:
 	http://wiki.metux.de/public/OpenSource_QM_Taskforce
 Patches / Fixes for a lot dozens of packages in dozens of versions:
	http://patches.metux.de/
---------------------------------------------------------------------

On Wed, Dec 12, 2007 at 12:27:01PM +0100, Enrico Weigelt wrote:
> No I'd like to request an feature for catching the console.
> IMHO, it's enough to have an option to vzctl start, which tells
> it to not to detach and bring the VE's console to the current tty.

Unfortunately this is much trickier than that.  The problem is that at
some point you'll want to detach the VE0's end; with standard Unix98
ptys this will result in SIGHUP being sent to all processes in the VE
whose controlling terminal is the console.  Besides, there are certain
implications for online migration of the VEs - you should leave no
references to the VE0 objects that can't be reconstructed on the
destination node.

So it looks like there's no pure userspace solution.  OTOH adding the
kernel support for it doesn't look impossible off-hand; I'll have a
look.

Roman.

Hi all,

here is a patch for vzctl to catch init output. output is written to VEROOT/var/log/init.log

I tested it with some debian templates (sysvinit), but it would be great is someone else tries/test it with other templates.

- Dietmar 

> -----Ursprüngliche Nachricht-----
> Von: devel-bounces@openvz.org 
> [mailto:devel-bounces@openvz.org] Im Auftrag von Roman Kagan
> Gesendet: Donnerstag, 13. Dezember 2007 09:16
> An: Enrico Weigelt
> Cc: OpenVZ developer list
> Betreff: Re: [Devel] Catching the console
> 
> On Wed, Dec 12, 2007 at 12:27:01PM +0100, Enrico Weigelt wrote:
> > No I'd like to request an feature for catching the console.
> > IMHO, it's enough to have an option to vzctl start, which 
> tells it to 
> > not to detach and bring the VE's console to the current tty.
> 
> Unfortunately this is much trickier than that.  The problem 
> is that at some point you'll want to detach the VE0's end; 
> with standard Unix98 ptys this will result in SIGHUP being 
> sent to all processes in the VE whose controlling terminal is 
> the console.  Besides, there are certain implications for 
> online migration of the VEs - you should leave no references 
> to the VE0 objects that can't be reconstructed on the 
> destination node.
> 
> So it looks like there's no pure userspace solution.  OTOH 
> adding the kernel support for it doesn't look impossible 
> off-hand; I'll have a look.
> 
> Roman.
>

* Roman Kagan <rkagan@sw.ru> wrote:

Hi,

> Unfortunately this is much trickier than that.  The problem is that at
> some point you'll want to detach the VE0's end; with standard Unix98
> ptys this will result in SIGHUP being sent to all processes in the VE
> whose controlling terminal is the console.  Besides, there are certain
> implications for online migration of the VEs - you should leave no
> references to the VE0 objects that can't be reconstructed on the
> destination node.

I just need it for debugging (eg. the startup process where no
remote access is available yet), so these problems aren't
important there.

If it really should be detachable, I suggest something like
screen(1), maybe implemented as 9P server.


cu
-- 
---------------------------------------------------------------------
 Enrico Weigelt    ==   metux IT service - http://www.metux.de/
---------------------------------------------------------------------
 Please visit the OpenSource QM Taskforce:
 	http://wiki.metux.de/public/OpenSource_QM_Taskforce
 Patches / Fixes for a lot dozens of packages in dozens of versions:
	http://patches.metux.de/
---------------------------------------------------------------------