From: Herbert Poetzl (herbert_at_13thfloor.at)
Date: Tue 12 Apr 2005 - 22:54:38 BST
On Tue, Apr 12, 2005 at 11:12:27PM +0200, Nicolas Costes wrote:
> Le mardi 12 Avril 2005 18:37, Herbert Poetzl a écrit :
> > you can compile in and enable the vserver debugging system
> > (kernel side support) will give you plenty of messages
> > once enabled too but if you 'know' what you're looking
> > for, it's probably easy to find ...
> Well, that's my problem, I don't know what to look for in the logs...
> This debug stuff seems a good idea. The messages go through Klogd, right ?
> > but I'm still pretty sure that it is simpler to find the
> > issue in an strace or maybe even in a debug log with
> > reasonably high debug level ...
> Well, this hasn't proven easy.
> > copy the entire system into a vserver and start it there
> > (after allowing for broadcasts and binding to the broadcast
> > address),
> This is interesting: I actually suspect something like that.
> What (where !) do you mean by allowing broadcasts ?
well, I'd say it won't work with ipx and such stuff
but if it is ip (broadcast) there is a way to get it
> It is a capability, if I remember correctly ?
yep #define CAP_NET_BROADCAST 11
adn you should allow the 'boradcast' address in
your vserver too (from the interface configuration)
net = 192.168.0.0
mask = 255.255.255.0
-> broadcast = 192.168.0.255
(or all networks 255.255.255.255)
not to confuse with multicast addresses ...
> > then, if it fails too, run a single tests (maybe
> > automated?) to do the necessary steps, strace both apps
> > (the one on the working server and the one inside the guest)
> > then compare the straces (with a little script maybe) and
> > look for differences (i.e. syscalls which succeed in one
> > trace but fail in the other, sections left out in either
> > trace, etc)
> Thank you very much for all thoses ideas, i'll have something to eat
> tommorow ;-)
> Vserver mailing list
Vserver mailing list