> I did not observe that before. Was that the clients doing updates or those just
> accessing Coda readonly?

	The clients doing updates.

> If some clients aggressively fetch files from Coda servers at the same time
> as other clients update files, either of them may see big variations
> in server response time and possibly disconnect. It might lead to unexpected
> conflicts, but I did not see crashed or hangs because of that.

	There shouldn't be conflicts since each machine writes to its own
directory.  We haven't seen any conflicts in quite awhile.  I haven't
noticed disconnects either...

> That should mean that clog fails three times one after another...
> Can you see the authentication attempts/fails in the AuthLog?

	I see lots of authentication grants in AuthLog and no auth failures. 

> Which clog do you use? The default one with Coda password authentication?
> You may want to try the modular one, see if it helps and otherwise motivate me
> badly to fix it :)

	The modular one?  I just searched through the coda source tree and I
only found one clog.c.  Where is the alternative version?  How is it
different?  Or am I misunderstanding something?

> I would not just restart venus after a crash, but reinit instead - as rvm
> state is probably corrupted and you can expect another crash or other
> weird behaviour.

	Hmmm.  OK.  Should I just do this as standard practice in my startup
script?  What's the negative?  I lose my cache and startup times are
slower?

> Some kind of "universal cure" is to watch for venus crashing (recompile to
> remove zombying?), then set the reinit flag for venus and reboot the machine.
> (hm, one more reason to not put clients on the same machines as servers -
> though in theory a server reboot might be acceptable, it is to no good anyway).
> 
> If your services are redundant, you would be able to survive even with
> such drastic measures.

	Yes, that would certainly work in our setup although it isn't pretty at
all and i wouldn't want the servers rebooting all the time.

> In an extreme, your company might consider contributing to the development,

	I wish we had the spare manpower...

	Thanks for your help, Ivan.  

	By the way, I've done an analysis of all programs that keep files open
on coda and have made sure that this no longer happens (at least in the
idle case).  I'm waiting anxiously to see if we get more signal 11's...

-- 
Patrick Walsh
eSoft Incorporated
303.444.1600 x3350
http://www.esoft.com/