Subject: Re: [vserver] Howto debug apps in a vserver for the missing capabilities
From: Herbert Poetzl <herbert@13thfloor.at>
Date: Sat, 6 Sep 2008 00:09:25 +0200

On Fri, Sep 05, 2008 at 10:34:38PM +0200, Manfred Heubach wrote:
> Hello, me again,
> 
> I have an application which I want to run in a vserver (it's TKsuite
> server from AGFEO - it's only available as 32bit, is linked against
> libcapi20-2 - my host is Debian Etch AMD64 - I thought the simplest way
> will be running it in vserver with Debian Sarge i386 ...)
> I have copied the capi device nodes into /dev of the guest. Inside the
> guest capiinfo can communicate with the card - so this should be ok.
> 
> I traced the system calls (strace) once from inside the guest and once
> from inside the host chrooted to the guest. Inside the guest capi
> communication fails at some point, inside the host (chrooted) it is
> running fine.
> This is the strace output in the (imo) relevant parts:
> 
> >From inside the host - chrooted to the guest (application is working):
> 
> 7211  write(12, "\0\17Icapi_b,p,9997:", 17 <unfinished ...>
> 7230  <... select resumed> )            = 1 (in [6], left {1, 0})
> 7211  <... write resumed> )             = 17
> 7230  read(6,  <unfinished ...>
> 7211  time( <unfinished ...>
> 7230  <... read resumed> "\0", 1)       = 1
> 7211  <... time resumed> NULL)          = 1220645195
> 7230  read(6,  <unfinished ...>
> 7211  getsockopt(5, SOL_SOCKET, SO_TYPE <unfinished ...>
> 7230  <... read resumed> "\17", 1)      = 1
> 7211  <... getsockopt resumed> , [1], [4]) = 0
> 7230  read(6,  <unfinished ...>
> 7211  getsockopt(9, SOL_SOCKET, SO_TYPE <unfinished ...>
> 7230  <... read resumed> "Icapi_b,p,9997:", 15) = 15
> 7211  <... getsockopt resumed> , [1], [4]) = 0
> 7211  getsockopt(11, SOL_SOCKET, SO_TYPE <unfinished ...>
> 7230  write(6, "\0\3O\0\0", 5 <unfinished ...>
> 7211  <... getsockopt resumed> , [1], [4]) = 0
> 7230  <... write resumed> )             = 5
> 7211  getsockopt(16, SOL_SOCKET, SO_TYPE <unfinished ...>
> 7230  getsockopt(6, SOL_SOCKET, SO_TYPE <unfinished ...>
> 7211  <... getsockopt resumed> , [1], [4]) = 0
> 7230  <... getsockopt resumed> , [1], [4]) = 0

> And from inside the guest
> 
> 6115  write(12, "\0\17Icapi_b,p,9997:", 17) = 17
> 6115  getsockopt(12, SOL_SOCKET, SO_TYPE, [1], [4]) = 0
> 6115  shutdown(12, 2 /* send and receive */) = -1 ENOTCONN (Transport
> endpoint is not connected)
> 6115  close(12)                         = 0

well, full traces would be required, with -s 9999
and -fF

> But in the end I have no idea :-(
> I can see it's doing a bit more inside the host - but I can't tell what.

my guess would be some socket connection to a
capi daemon (running on the host?)

or could be implicit module loading as well

> Is there a general way howto debug such cases? 

> I think it's all about a missing capability. 

well, that's easy to check, just give the guest
all capabilities and retry ...

> But I don't see how I can determine it 
> (well - trial and error would perhaps do the job).

strace -fF is a good start to narrow it down,
check what actually 'fails' and look for the
capabilities required

HTH,
Herbert

> Regards
> Manfred