Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!zaphod.mps.ohio-state.edu!wuarchive!rice!rice!sun-spots-request
From: jim@cs.strath.ac.uk (Jim Reid)
Newsgroups: comp.sys.sun
Subject: Re: /bin/login hangs if an NFS server down?
Keywords: Networks
Message-ID: <1990Oct7.231455.4293@rice.edu>
Date: 7 Oct 90 21:30:00 GMT
Sender: sun-spots-request@rice.edu
Organization: Sun-Spots
Lines: 28
Approved: Sun-Spots@rice.edu
Originator: spots@walhalla.rice.edu
X-Sun-Spots-Digest: Volume 9, Issue 340, message 1

In article <1990Aug29.231300.10232@rice.edu> dank@moc.jpl.nasa.gov (Dan Kegel) writes:

|We run Solbourne's SunOS 4.0.1, without quotas.  Whenever an NFS server on
|my network is down, logins seem to take forever even if the filesystem
|provided by the server has nothing to do with the user who is logging in.

|Does anybody know what the heck /bin/login is doing in that child process
|that takes 1'16" to terminate?  Is it secretly doing a df?

No.

When login forks and execs /bin/csh, csh does a getwd() to determine its
current working directory. This involves getting the name and inode number
of every file in the parent directory. Comparing the inode number for '.'
(the current directory) with each name/inode number pair in the parent
directory gives the filename of the current directory. This procedure is
executed in successive parent directories (building the pathname as it
goes along) until it hits '/' where the inode numbers  for '.' and '..'
are the same.

Now to get the inode number for an NFS mount point, the kernel has to make
a request to the NFS server. If the server is down and the filesystem hard
mounted, the kernel will wait forever for a reply to the NFS request it
made. I suppose that there must be a mount point for a dead NFS server
somewhere in one of the directories between the users home directory and
'/'.

		Jim