Subject: Re: [vserver] upstart and vserver
From: Herbert Poetzl <herbert@13thfloor.at>
Date: Tue, 4 Jan 2011 05:13:41 +0100

On Tue, Jan 04, 2011 at 10:14:11AM +0800, Jeff Jansen wrote:
> On Wednesday 22,December,2010 12:01 AM, Herbert Poetzl wrote:
> > if you are interested in tracking this down, please pay a visit
> > to the IRC channel (#vserver @ irc.oftc.net) where we can debug
> > this in detail (you need a test system and a kernel build tree
> > to test with :)

> I definitely would be interested in working on this.  Pardoning 
> my ignorance, what timezone are you in? :-)  I'm in UTC+8.

I'm in GMT+1 but as you can see from this reply, my
'working hours' do not match the timezone :)

> Right now I'm working on this in Virtual Box.  So I've got 
> Debian Squeeze as the host running in Vbox and then Lucid 
> as a vserver guest.

I'd probably use kvm with a serial console instead,
but if that works for you, it's fine for me ...

> (I see exactly the same behavior in VBox as on a "real" server.  
> Will troubleshooting work in Virtual Box or do I need to install 
> all this on a physical server again?

there shouldn't be any (relevant) difference between them, 
so no need to use a physical machine ..

> >> If I go into "/etc/init/ssh.conf" and comment out the 
> >> "expect fork" line and then change 'exec sshd' to 'exec
> >> sshd -d' (so sshd won't fork), then SSH starts and stops 
> >> correctly using upstart.

> > I presume this simply disables the ptrace completely, 

> Yes, exactly. The "expect fork/daemon" config line tells Upstart
> to use ptrace to "follow" the program as it forks and exits, so it
> doesn't record the wrong PID. By removing that and telling the program
> not to fork and "daemonize", upstart properly tracks the PID without
> using ptrace.

so we basically have to find out where ptrace behaves
differently in a guest than on the 'host', which means
that you need to have two setups, the existing one and
one with the 'guest' as 'host' installation to compare

best,
Herbert

> > note that I'm not convinced that ptracing services is a good 
> > idea in the first place, mainly because of performance 
> > implications.

> The upstart developer agrees with you. He says at this point he's
> convinced ptrace is NOT the way to do this and is working on a rewrite
> of the functionality for the next version. But no timeframe for the
> new version nor does that solve the problem for distros like lucid
> which use the present version.

> Thanks again.

> Jeff Jansen