UNIX Hints & Hacks
Chapter 2: Networking
|
Sections in this Chapter: |
|
|
|
|
|
|
|
2.7 Unmounting and Busy Devices |
||
|
|
|
|||
|
|
|
|
UNIX Hints & Hacks |
|
|||||||||||||||||||||
|
Chapter 2: Networking |
|
|||||||||||||||||||||
|
2.7 Unmounting and Busy Devices
Learn to deal with mounted devices that need to be unmounted when they are busy being used by someone or have files.
Syntax:
kill PID showmount -a unmount fsname
There are numerous ways to attempt to unmount various devices. In all cases, when there is a device that is busy and cannot be unmounted, you have to ask yourself:
Who has the control of the mounted device?
What is the device and what is being done?
One of the hardest things is tracking down who or what has the device open. Mounted devices can be mounted from either a local system or from remote systems. They can even be remotely mounted from multiple systems. Systems with local mounted devices have disk drives, storage arrays, or CD-ROM drives. Systems that are remotely mounting devices are usually attaching to the same exact devices, only over the network.
UNIX doesn't tell you which device is being used by individual users. You sometimes have to do some deductive reasoning or execute a series of commands and, through a process of elimination, you find the user or process responsible for putting the device into a busy state. Start looking locally, and then broaden your search out to the network.
|
Note - Before you begin, log in as root. Do not switch to root user with the su command. Make sure there are no open shells in the device you want to unmount. It saves much-needed time in the end. |
This example features a disk mounted /disk2. Try to unmount the device.
rocket # unmount /disk2 /disk2: Resource Busy
Then check for local processes using the device. There might be a process that is using the device. If so, you can contact the user associated with the process and have the process killed.
rocket # ps -ef USER PID %CPU %MEM SZ RSS TT S START TIME COMMAND root 205 0.0 0.3 2464 420 ? S 22:04:30 0:03 /usr/lib/lpsched gloriar 21960 0.0 0.9 2320 1672 pts/5 S 22:07:31 0:04 /disk2/bin/satan root 340 0.0 0.9 2320 1672 ? S 22:07:31 0:04 /usr/lib/sendmail
rocket # kill 21960
If that that doesn't do the trick and the number of users on the system or workstation is small, you can contact each user and make them exit the area. This is typically available only on workstations with one or two users. If this is needed on a server, especially a production server, the unmounting of the device should be scheduled. Notification to users should always be a high priority, so they are never left with any surprises.
rocket # w | awk '{ print $1 }' | finger -s Login Name TTY Idle When Office jdoe John D. q0 1:19 Thu 11:15 asmith A. Smith q1 1:16 Wed 17:11 johnson H. Johnson q3 51 Wed 18:05 gloriar Gloria R. q5 02 Wed 20:00
This one-liner collects the information from the w command, strips out the user IDs with the awk command, and performs a short-form finger on each ID. This tells you by name who is on the system so you can contact them directly. If they are doing something important, the device's busyness just saved you.
rocket # unmount /disk2 /disk2: Resource Busy
If, after all this, the mount device is still busy, you must begin to search for systems that are remotely connected to the device. Using the showmount command you can see all the remote machines that are connected to the local system. This command displays not only the remote systems but also the devices they are mounted to.
rocket # showmount -a shuttle:/disk2 pilot:/disk2
Flavor: Solaris
Syntax:
dfmounts [ -F nfs ]
There is a command called dfmounts that is similar to showmount. dfmounts shows the local resources that are shared through a distributed filesystem, FSType, and the list of clients that have the resource mounted.
rocket # dfmounts -F nfs RESOURCE SERVER PATHNAME CLIENTS - rocket /disk2 shuttle - rocket /local shuttle - rocket /disk2 pilot
Proceed to each of the remote systems and attempt to unmount the device. If no processes and no users are accessing the device, it unmounts without any problems.
rocket # telnet shuttle Login: root Password:
shuttle # df -k Filesystem Type kbytes use avail %use Mounted on /dev/root xfs 2051936 1910832 141104 94 / rocket:/disk2 nfs 33343 16739 16604 51 /disk2
shuttle # unmount rocket:/disk2 shuttle # df -k Filesystem Type kbytes use avail %use Mounted on /dev/root xfs 2051936 1910832 141104 94 /
shuttle # exit
While progressing through each of the remote systems, you might come to one that still does not unmount.
rocket # telnet pilot Login: root Password:
shuttle # df -k Filesystem Type kbytes use avail %use Mounted on /dev/root xfs 2051936 1910832 141104 94 / rocket:/disk2 nfs 33343 16739 16604 51 /disk2
shuttle # unmount rocket:/disk2 /disk2: Resource Busy
At this point, repeat the beginning steps. Search for processes or users that might be keeping the device busy and work with them to free up the resource. It is a tedious task but the safest way.
If you believe every path has been exhausted and you still want to unmount this device, make sure that there are no system files that reside in this area. Go through UNIX trees and watch for soft links that might have been put in place.
rocket #ls -al /usr | grep ^l lrwxrwxrwx 1 root 11 Oct 13 1996 mail -> /disk2/var/mail/ lrwxrwxrwx 1 root 11 Oct 13 1996 man -> ./share/man/ lrwxrwxrwx 1 root 15 Oct 13 1996 pub -> ./share/lib/pub/ lrwxrwxrwx 1 root 12 Oct 13 1996 spool -> ../disk2/var/spool/ lrwxrwxrwx 1 root 11 Oct 13 1996 src -> ./share/src/ lrwxrwxrwx 1 root 10 Oct 13 1996 tmp -> ../disk2/var/tmp/
In this case the resource is always busy, because sendmail always has files open on the areas of spool and mail. Keep your eyes open for other system applications that might be using the resource you are trying to free up.
Flavor: Irix
Syntax:
umount -k fsname
On the SGI systems, Irix has a -k option that can be passed to unmount. This option enables you to tell the device, "No matter what, you are unmounting this device!"
shuttle # unmount -k rocket:/disk2
This can easily make your phone ring by angry users, so be careful using it. I have also seen the option work about 60% of the time. When it does work, it saves time in having to reboot the system to release the device.
There are two other alternatives to releasing the device that I know you don't want to hear, but I still have to mention them. Take the system down by halting it or reboot the system.
The situations in which you want to unmount a device can be anything from labeling a disk on-the-fly, unmounting a CD from a CD-ROM drive, dealing with stale mount points, or moving NFS mount points. It is a safe and clean way to do things and keep users off the device when only you need access to it without having to take the system down.
Always double-check the open shells you have on your desktop or console terminal. I can't begin to tell you how many times system administrators have been caught by this. They would verify the device to unmount, switch to the root account, and then change directories to the root level or the system. All the while, they forget that their original shell underneath is still inside the device that is trying to be unmounted.
Another variation is to log in to the console terminal, examine the device to be unmounted, and then start up the window manager under the root account. All new shells start at the root level, but once again the original login shell is sitting inside the device.
Storage devices (Disk drives and arrays) are notorious for crashing systems when they are about to die. It is a good idea--if the drive is making noise or sending I/O errors to the console--to get as much backed up as possible and unmount it, making it inactive to the system until you can get it replaced or schedule some down time.
Many environments have very little disk space so, as the need for more disk space begins to expand, you find yourself becoming very familiar with NFS mount and unmount commands, especially when a server goes down and all the mount points go stale. The unmount command is useful when this occurs.
Some system administrators have been known to use the unmount command when performing their backups. By freezing a disk for backups on a nightly basis, the device is made unavailable to the users so clean backups can be executed without any files or databases being modified. This isn't highly recommended without a good set of procedures in place.
Man pages:
showmount, umount
|
UNIX Hints & Hacks |
|
|||||||||||||||||||||
|
Chapter 2: Networking |
|
|||||||||||||||||||||
|
© Copyright Macmillan USA. All rights reserved.