On Monday 20,December,2010 02:36 PM, Herbert Poetzl wrote:
>> However, I still find that I can't stop and start services through
>> upstart in a guest if the upstart configuration contains "expect fork"
>> or "expect daemon". Upstart hangs.
>
> what does 'hangs' mean here?
The prompt just sits there and never returns.
> anything relevant in the (upstart) logs?
I turned on all the debugging and ran 'strace -f -p 1' in the guest
while I ran "start ssh". The log shows:
Dec 20 22:14:28 LUCID init: Failed to spawn ssh main process: unable to
set trace: Operation not permitted
and the strace shows:
[pid 15231] ptrace(PTRACE_TRACEME, 0, 0, 0) = -1 EPERM (Operation not
permitted)
> does it work properly on an unpatched system with vanilla kernel?
Yes, ssh starts and stops fine on a "normal" install of Lucid (i.e not a
vserver guest) using the standard upstart tools - 'start ssh', 'stop
ssh', etc.
>> Running upstart commands manually with --verbose and watching an
>> strace seems to show that upstart gets the pid of the process wrong.
>> So my guess is that it's related to this bug,
>> "http://bugs.launchpad.net/upstart/+bug/530779", about upstart using
>> ptrace() to track pids when a process forks and then exits.
>
> so, the important part is to check if ptrace reports something
> wrong inside a Linux-VServer guest then, if so, we should fix
> it, otherwise it's an upstart bug and has to be fixed there ...
>
> also, does manually mean from an ssh logon or via 'enter'?
Either using 'vserver ... enter' or SSHing in gives the same issue.
> and does it work properly when the guest shuts down?
Yes, the vserver starts up (vserver ... start) and stops with no errors.
But there's nothing in the logs when it starts. I've even added ">>
/tmp/upstart.log" to all various parts of the "/etc/init/ssh" upstart
script per this page
(http://upstart.ubuntu.com/wiki/Debugging?highlight=%28%28CategoryDoc%29%29)
and nothing ever gets written to the log. (And yes, I made /tmp part of
the "real" filesystem, not tmpfs.) :-)
>> So does anyone have any ideas where to go next?
>
> first, I'd update to 2.6.36.x with the latest patch and the
> most recent util-vserver, because that's where all the
> updates and fixes go, and check that the 'issue' still
> exists there ...
OK, I'm compiling the latest kernel with the vserver patches and the
latest util-vserver package. I'll let you know what it turns up when I
use them.
>> Is there some way to debug this problem better?
>
> enabling Linux-VServer debugging for that kernel would be
> advised to get some information on the Linux-VServer side
> and of course, enabling whatever debug log upstart can
> provide is probably a good idea too ...
OK, I've enabled that for the new kernel as well.
> if it is an issue caused by ptrace reporting something
> wrong inside a Linux-VServer guest you do not really
> have to worry anymore, as it will be considered a bug
> and fixed ASAP ...
Thanks, as always! :-)
Jeff Jansen
Received on Mon Dec 20 14:30:22 2010