Coda File System

Re: codasrv crashing

From: Jan Harkes <jaharkes_at_cs.cmu.edu>
Date: Wed, 19 Jan 2005 10:10:33 -0500
On Wed, Jan 19, 2005 at 09:51:04AM +0100, Michael Tautschnig wrote:
> Sorry, I should have added this (from SrvLog):
> 
> 09:36:47 VAttachVolumeById: vol 100000d (brauer.0) attached and online
> 09:36:47 create: volume 100000d (brauer.0) created
> 09:36:47 S_VolSetLogParms: res flag on volume 0x100000d set to 0 
> (resolution disabled)
> 09:36:47 S_VolSetLogParms: volume 100000d log parms set
> 09:36:48 New Data Base received VLDB created.  Search lengths: RO 0, RW 0, 
> BK 0.

I'm not sure whether those search lengths are supposed to be 0 here. I
would expect something like RO 0, RW 13, BK 0. This would seem like it
just created an empty (or corrupted) VLDB file. Are there earlier lines
where these numbers look normal?

> 09:36:48 VRDB created, 13 entries

I guess this was the 13th volume.

> 09:36:49 VLDBLookup: VLDB_size unset. Calling VCheckVLDB()
> 09:36:49 ****** FILE SERVER INTERRUPTED BY SIGNAL 8 ******

And the server tries to re-read the empty (or corrupted) VLDB file and
dies. The SIGNAL 8 is unusual, normally we see a segfault/null ptr
dereference which is signal 11. According to the manpage this is
probably a floating point exception, strange.

> >I may restart my server, but then "volutil getvolumelist" reports:
> >V_BindToServer: binding to host puma
> >GetVolumeList finished successfully

When the server is coming up, does it show things like 'volume foo attached'?

Getvolumelist gets the list of volumes this server is reponsible for.
The VLDB contains the list of all volume in your realm (i.e. on all
possible servers). Since the server isn't returning anything useful for
getvolumelist, it seems like it doesn't know there actually were volumes
created.

...
On the off chance, do you happen to run linux and have the ipv6 kernel
module loaded? I found an rpc2 problem which prevented the SFTP
sideeffects from completing because volutil sends packets with an ipv4
address but receives the responses from the corresponding ipv4-in-ipv6
address and it concludes someone is trying to fool it and drops the
replies.
...

Jan
Received on 2005-01-19 10:11:45