Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!usc!venera.isi.edu!raveling
From: raveling@venera.isi.edu (Paul Raveling)
Newsgroups: comp.sys.hp
Subject: Re: HP-UX 6.5 NFS problem on cnodes. (A help question -- 2 pages)
Message-ID: <8840@venera.isi.edu>
Date: 5 Jul 89 15:35:12 GMT
References: <9773@boulder.Colorado.EDU> <7540029@hpfclp.SDE.HP.COM>
Reply-To: raveling@venera.isi.edu (Paul Raveling)
Organization: Information Sciences Institute, Univ. of So. California
Lines: 49

In article <7540029@hpfclp.SDE.HP.COM> diamant@hpfclp.SDE.HP.COM (John Diamant) writes:
>> However, we are planning to upgrading from HP-UX 6.2 to 6.5 very soon.  We
>> discovered in the release notes a very serious problem.  Apparently, if
>> you are logged in on a cnode and your cwd is an nfs directory, you can not
>> start up csh.
>
>The problem referred to in the release notes is not with NFS, but with
>RFA (netunam).  I am running 6.5 on my cluster and just confirmed that
>csh starts up just fine when my current directory is under an NFS mount point.

	We have no problem starting csh when all hosts are alive
	that we have NFS mounts on, but have experienced inability
	to start csh when any of those hosts has gone down.  (Further
	qualifications follow.)  This happens if ANY of those hosts
	goes down -- it's not necessary to have an file open on the
	defunct host.  The situation cures itself when the dead host
	revives.

	What usually happens is assorted operations within X windows
	start looking catatonic.  I usually try to SU in an existing
	window or open a new xterm window to check it out; in both
	cases starting up the new csh hangs.

	However, in these circumstances csh comes up successfully as
	a login shell.  I've been able to log out & log in again as
	root, using csh, to unmount the offending file system.  I've
	also logged in as myself with csh as the login shell to bring
	up X without unmounting anything, and X comes up, but X clients
	that depend on csh hang.

	It appears that our Sun users have the same problem, suggesting
	it's purely an NFS behavior.  That 2nd hand info -- I haven't
	personally looked at it on Suns.

	To confuse matters more, it appeared that for a brief time
	the problem went away, then came back.  Perhaps it's sensitive
	to some piece of setup in .cshrc files, but we haven't spotted
	it yet.

	BTW, we're not running totally diskless.  Each workstation
	has local swap space and enough file system to have a local
	kernel, /bin, and /etc directories.  Practically everything
	else, including /usr and all users' home directories, is
	mounted via NFS.


----------------
Paul Raveling
Raveling@isi.edu