Subject: Re: [vserver] Howto debug apps in a vserver for the missing capabilities
From: Manfred Heubach <entwicklung@heubach-edv.de>
Date: Fri, 05 Sep 2008 22:51:33 +0200

Maybe I found something already. I recognized that /proc/capi is not
visible inside the guest. On the other hand strace output didn't show
access on /proc/capi. I'm sure it's somewhere in the manuals how I can
unhide certain files in /proc - but maybe somebody is faster answering
here than me looking it up.

Regards
Manfred

Manfred Heubach schrieb:
> 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 i
> s not connected)
> 6115  close(12)                         = 0
>
>
>
> 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.
>
> Is there a general way howto debug such cases? I think it's all about a
> missing capability. But I don't see how I can determine it (well - trial
> and error would perhaps do the job).
>
> Regards
> Manfred
>