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