SUMMARY:dtlogin hangs when remote /usr/local unavaillable

From: Charles Vachon <cvachon2_at_mrn.gouv.qc.ca>
Date: Wed, 13 Oct 1999 16:23:37 -0400

Hallo again Admins,

Thanks to the following people for replying so quickly:

Richard Bemrose <rb237_at_phy.cam.ac.uk>
Oisin McGuinness <oisin_at_sbcm.com>
John J. Francini <francini_at_progress.com>
"Leonard, Roger" <rleonard_at_cvty.com>

#-#-# The original message is appended at the end of this one #-#-#

As for the dtlogin hanging problem, with suggestions received, I was
able to figure out a workaround. I still do not know what dtlogin (I
should say CDE apps in general, in fact) tries to find in /usr/local,
however.

Roger suggests:
>make sure your nfs mounts are using the bg option and not hardmounted.
look
>in man mount explains it. it sounds like CDE is doing some sort of dir
>lookup and the fact that one of your nfs mounts is gone is causing
problems.

That solved my problem. Now instead of having the NFS client retrying
forever when a NFS server goes down, the client retries for a while and
finally gives up. The CDE is less responsive in this situation, but at
least, it works. Note that soft mounts are only safe when the remote
file system is mounted read-only, which is the case with my /usr/local.

Oisin's comments point to another promising direction:
>If you have NFS mounts they should be at 3 levels down; not 1; not 2.
>So instead of mounting at /usr/local, mount at something like
>/nfs/machine-name/file-sys-name, and
>make /usr/local a symbolic link.
>
>This is because essentially anything (in your case) traversing the /usr

>heirarchy (does any software not have to?) will essentially stat (do
man stat)
>everything in /usr, and will hang.

I tried this solution, but unfortunately, it did not work for me.
dtlogin hung again after making /usr/local a symlink to a NFS-mounted
directory. Perhaps I lack something else for this one to work?

As for the relevance of sharing /usr/local to a number of hosts with
NFS, I received the following comments:

Richard Bemrose:

>We regard the "/usr/local" directory `local' to each workstation. For
>example, we install there such software as web servers, netscape,
MTA's,
>SSH etc which we do not want to NFS mount. All other applications are
>NFS mounted at "/usr/apps" (some others use "/usr/opts"). We do however

>need to set the "LD_LIBRARY_PATH" to "/usr/apps/lib/".

John Francini:
>As to "violating the purpose of /usr/local" -- my view is that
>/usr/local is for _site-specific_ stuff, not necessarily stuff
>specific to a given host. I use /usr/local because I know it's (a)
>always in the search path, (b) not going to be mucked with by DU/T64U
>upgrades, and (c) the default expected place that certain installers
>[such as GNU tools] expect to be able to put things.
>Just my US$0.02,

Thanks again gentlemen. Thoughtful comments as always.

CV

#-#-#-#-#-#-#- Original post follows -#-#-#-#-#-#-#

Hello Tru64 admins,

I have been fighting with this problem for a while, and I still don't
have a clue as to what happens. So maybe some of you are more familiar
with CDE than me, and have the answer.

Here is what happens:

We do share local and free software to a few TU 4.0D workstations here
using /usr/local. One server, named serv215, has all such software
installed in it's /usr/local hierarchy, and workstations mount
serv215:/usr/local over their /usr/local. So far, so good.

I noticed a problem when serv215 goes down, and workstations are still
NFS-mounting it's /usr/local. When a CDE session is ended at a
workstation (with the EXIT buffon), it's dtlogin screen does not cycle
back to a normal state. Instead, one gets a black screen with a
hourglass cursor, and nothing can be done to proceed any further. The
moment serv215 is restarted and it's NFS daemons are running,
workstations regain access to /usr/local and the dtlogin screen appears
again an it's normal operation is resumed. This behavior has been
observed both on the workstation's console and with Exceed X-server
connected to the workstation . What is strange is that /usr/local
contains nothing relevant to CDE. I even managed to remove references to

it altogether from the resources Dtlogin*userPath and Dtlogin*systemPath

in the /etc/dt/config/Xconfig file. So far I can not figure out why
/usr/local is important to dtlogin.

BTW, I would like to have your opinion on sharing software by remote
mounting /usr/local. Is this something of common practice, or does it
violate the normal use of /usr/local. Maybe a philosophical question,
but interesting indeed. If you have a better way of doing this and are
willing to share (no pun intended) your views, I welcome your comments.

TIA/will summarize
--
===============================================
Charles Vachon tel: (418) 627-6355 x2760
  email: cvachon2_at_mrn.gouv.qc.ca
  Administrateur de système
  FRCQ/Ministère des Ressources
  Naturelles du Québec
===============================================
Received on Wed Oct 13 1999 - 20:25:58 NZDT

This archive was generated by hypermail 2.4.0 : Wed Nov 08 2023 - 11:53:39 NZDT