Re: CVS and NFS

[Derek Robert Price]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Andy Jones wrote:

>::shrug::  All I can say for sure is,  I shut down NFS and it still
didn't work; then I restarted pserver and it worked.  You're right,
there *may* be no connection between the action and the result in that
last statement.  I suppose I'd better just chalk it up to Spontaneous
Reality Failure and hope it doesn't happen again....


Again, if there is any connection, then it likely has to do with your
(x)inetd and not CVS.  CVS is started by inetd & then talks to clients
via its own stdin and stdout, which data inetd relays back-and-forth
for CVS.  The only state any single CVS server maintains is for its
one client connection and then any temporary locks it creates in the
repository and permanent changes it makes to the RCS archives.  The
only thing that should affect other CVS servers, and thus other
clients, is the locks (which a client is notified about when
encountered), and the archive data which is retrieved.

It's possible that your NFS failure somehow resulted in hung server
processes, which could hit something like a process limit in your
inetd.  I think that defaults pretty high, but if anyone had set it to
a low number like 5 or 10...  Of course, it's been a while since I've
seen a reproducible way to hang a server without a client that was
still running.

>I hope that everyone reading this understands I'm not attempting to
apportion blame here; just trying to work out if, indeed, I do have a
cause/effect link.


Of course.  And I'm just trying to tell you you are probably barking
up the wrong tree based on what I know of the inner workings of CVS.
"restarting" pserver involves restarting inetd, not CVS, really, and
again, there is very little stateful information stored by one CVS
server that should affect another, other than locks and the archive
info itself.  Hrm...  Where is your CVS executable stored?  It could
be that the same NFS hiccup that got to you got to your server and
inetd hung looking via NFS for the executable.  I don't know that that
could really happen, but it's a thought.  I don't know why in this
case that the server wouldn't come back immediately after restarting
NFS either.  Perhaps the main inetd thread can be hung during
attempted NFS access and inetd was still waiting for a timeout form a
previous NFS access when you tried to connect again?

Derek

- --
                *8^)

Email: address@hidden

Get CVS support at <http://ximbiot.com>!
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFAh8OELD1OTBfyMaQRAn0JAJ4766f/X0wCNjX/UuQIjBmMdMUgbACfT00w
8pxMVQGs9XiGEA3E9EVEHDA=
=nk8N
-----END PGP SIGNATURE-----