Coda File System

Re: local-client sticky failure

From: Jan Harkes <jaharkes_at_cs.cmu.edu>
Date: Tue, 18 May 2004 22:59:45 -0400
On Fri, May 14, 2004 at 04:33:14PM -0400, shivers_at_cc.gatech.edu wrote:
> I have a coda client installed on the same box as the coda server it accesses.
> For some reason, this seems much flakier than the external clients. It
> frequently bombs out:
... 
> If I bounce the client using the /etc/init.d script, it comes back
> up successfully, but consistently dies as soon as I hit it with a
>     ctokens
> The log looks like this
>     16:29:22 RPC2_Bind to 129.42.208.182 port 11957 for callback failed RPC2_NOBINDING (F)
>     16:29:22 Worker2: Unbinding RPC connection 14464
> and I get the same venus zombie-waiting-for-gdb lossage in the venus logs.

There should be no relation between calling ctokens and the network
connections. The only thing I can thing of is that when no realms are
specified, ctokens does a readdir on the fake toplevel /coda directory
to discover which realms the client knows about. But again, this is a
dynamically generated and doesn't require network calls. At least the
readdir operation used by ctokens doesn't, an ls will often try to get
the attributes of all objects so that it can colorize or show the
mtime/inode/size/linkcount information.

Also a local client still talks to the server using the same UDP
protocol, any differences in behaviour can only be caused by either the
lower latency of the connection, or the higher system load when both the
client and the server are hitting the disk simultaneously and cause the
disk to start trashing.

You must have hit some timing related bug in the client code which
corrupted the client's persistent RVM state.

Jan
Received on 2004-05-18 23:03:17