My original question:
> I had a machine on the network which had its partitions mounted by other
> hosts using NFS. This machine was shutdown and removed, but the other
> hosts still had its partitions NFS mounted. Now, commands like df, mount,
> umount and login all hang for a long time. Is there anyway to get rid of
> these NFS mounts without doing a shutdown on all these hosts?
Thanks for the replies. Crashes and a power failure :-( fixed my
original problem :-) so I never got a chance to try any of your
solutions. Here's a summary. A number of people suggested using the
automounter to prevent this problem from happening. A couple suggested
deleting the mounts from the /etc/mtab file. Some suggested umount
which I already tried, but a umount request just sat there doing nothing
for hours. BTW the mounts were not listed in the /etc/fstab file. I
just mounted them from the command line using:
mount -vt nfs host:/part /host/part
AT> My comments are prefixed with "AT>"
From: watmath!ASC.SLB.COM!holle Kathy Holle Schlumberger
If you can't /etc/umount, then the only thing I know to do is to reboot.
You don't say whether you are running automount. You might try (and this
could be bad so try it on your machine) to stop and start mountd.
-- From: Roy Smith <watmath!alanine.phri.nyu.edu!roy> There is no inherent reason why you can't umount the NFS file systems, but the odds are that you won't be able to because they will be busy.This won't help your immediate situation, but we set our NFS mount points up carefully to avoid the sort of problem you are having. We have a directory called /nfs on each client, with a subdirectory for each server. Every imported file system gets mounted in the particular servers directory. Thus, if I import file systems a and b from server foo, they get mounted in /nfs/foo/a and /nfs/foo/b. File systems c and d from server bar would go in /nfs/bar/c and /nfs/bar/d. Now, at least in theory, if foo were to go down, I could do something like "chmod 000 /nfs/foo" so any attempt to access its file systems would fail with 'permission denied' when /nfs/foo was touched, instead of hanging when /nfs/foo/[ab] was touched.
AT> Good idea. -- From: watmath!uunet.UU.NET!deltam!flyer!mark (mark galbraith) Try just unmounting them. The unmount request will timeout after about two minutes and from then on the mount command should not show the partition.
AT> I already tried this and it never timed out. -- From: watmath!mundo.eco.utexas.edu!tyen (Anthony Yen) Look up the chapter on mounting and unmounting filesystems in Sun's "System and Network Administration Manual" for more details. For your particular situation, you will need to do the following on each host that mounts the now-removed partitions:
- Become root. - Start your editor on /etc/fstab - Delete any line that references the now-defunct partitions - Save changes - Execute the command "mount -a", which will re-mount all partitions listed in the /etc/fstab file
AT> There was already no reference to them in /etc/fstab so this won't AT> work. -- From: Bob Drzyzgula Federal Reserve Board rcd@fed.frb.gov Best thing I have ever found is to locate a workstation somewhere that no one is using, and boot it up with the dead machine's name and IP address, exporting directories with the same names as the ones that are hanging everything up. Once this machine comes up, it will dupe all the other machines in the net in to thinking the server is back up. But the NFS protocol won't be completely fooled, because it will recognize that the new "filesystems" don't match the old, and it will give a "Stale NFS Handle" message every time you try to access it. But since this is an immediate error rather than a timeout situation, the protocol won't freze up and you will be able to do your umounts.
Smoke and mirrors. I've been messing with these machines for 5 years and haven't found a better way :-(. Didn't even think of this one til a couple of years ago. NFS does have it's flaws. If you learn anything more straightforward, let me know. -- From: watmath!meaddata.com!keves (Brian Keves - Consultant) The best way is to use the automounter instead of fstab to specify your NFS mounted filesystems. But you have to do that ahead of time. [...] The easiest way to make sure that you do not have any problems is to reboot each host that has the filesystem NFS mounted. There is a good chance that most of those systems are hung anyways, so you will probably have to go to each one and L1-A them if you cannot reboot them remotely.
AT> None of the systems were hung. Just some commands hung for a AT> long time. -- From: watmath!Sun.COM!synergy!sun!fourx.Aus!kevin (Kevin Sheehan) Use the automounter - that way the mounts decay automatically... l & h, kev -- From: watmath!beowolf.tcs.com!shipley Nope, (and Sun does not seem to care) -Pete -- From: watmath!bit!jayl (Jay Lessert) Nope. -- From: Robert L Krawitz <watmath!Think.COM!rlk> Yes -- kill all processes that are waiting for any of these filesystems, and run umount -a on all of the hosts. It's probably faster to reboot them. -- From: watmath!HQ.Ileaf.COM!stuart (Stuart Freedman {x1708}) Try logging in as root & doing a umount. This usually works, unless your system is already hung on the mount. (Also, make sure you use intr & bg options on the mount entry in your fstab. If you can afford to make it a soft mount as well, then you shouldn't have any hang problems.) -- From: watmath!athena.qualcomm.com!mphillips Marc "Phil" Phillips You might try : vi /etc/mtab and remove the lines that contain the machine you got rid of. -- From: watmath!ads.com!dglo (Dave Glowacki) If I get really annoyed, I edit 'em out of /etc/mtab. It may not be officially sanctioned, but it works. -- From: Rick Dipper <watmath!computer-science.manchester.ac.uk!rick> lost of re-booting. What would have been best would to umount before the firts machine was shutdown. if you wait long enough the mounts will "time-out" anyway
AT> I would have done the umount on all the hosts if I had a chance. AT> Anyway, the mounts didn't ``timeout'' over the next day.
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:06:15 CDT