petitp@divsun.unige.ch (Dominique Petitpierre) (06/07/90)
After posting the summary of answers to my "umount" problem, I received more informations, and several request for the location of the sources of the program "ofiles". This is my last summary on this topic. Please mail your followups directly to the SunSpots list. Here is the contribution of Joerg Lehners <lehners@uniol.uucp>: |>[...] |>Here are the situations I know that prevent "umount" to unmount a |>filesystem: |>1) A process has an open file on the filesystem. | |This is slightly incorrect: |an umount will return EBUSY, when the kernel has an inode of that |filesystem active. Sure, this is almost all time relating to an open |file of that filesystem or an working directory on that filesystem |or an active executable image of that filesystem. | |>2) A process has its current working directory (cwd) on the filesystem. |>3) A process has its "text" on the filesystem (was true for SunOS 3.4, seems |> to be false for 4.03) |>4) another filesystem is mounted in a subdirectory of the filesystem. |>5) a client has NFS mounted a directory on the filesytem (only |> for local filesystems) | |So all your 5 cases refer to the fact of an active inode in the kernel |of that filesystem. In case 4 and 5 the kernel holds the inode for |the moint point of that filesystem active. | |>Are there any other cases? | |Yup there are. Maybe I'm wrong in this relating to SunOS. | |An inode is active in the kernel when process accounting |via acct(2) is active. |The kernel holds an inode active, when there were sticky Bit executables |executed. |The last is true for System V.3 (at least for the verson we run here). |Then you need to turn off the t-bits manually. | |Another possibility is a kernel reference counting bug. When the kernel |is wrong about the inode reference count the inode is active although |all cases above are false. | |The best solution is to examine the inode table of the kernel directly. |I don't know how to do it on SunOS (might be pstat). On System V |there is a command crash to examine various kernel structures. and the contribution of Don "Truck" Lewis <del@mlb.semi.harris.com>: |I have seen this happen occasionally. I thing something gets confused |and the partition looks like it is busy when its really not. It looked |to me like it was correlated with "on". and the contribution of <brent@Eng.Sun.com>: |You might be interested in a new command available in SunOS 4.1. It comes |courtesy of RFS (but it works for NFS too). | |FUSER(8) MAINTENANCE COMMANDS FUSER(8) | |NAME | fuser - identify processes using a file or file structure | |SYNOPSIS | /usr/etc/fuser [ -ku ] filename|resource [ - ] [[ -ku ] | filename|resource ] | |DESCRIPTION | fuser outputs the process IDs of the processes that are | using the filenames or remote resources specified as argu- | ments. Each process ID is followed by a letter code. Pos- | sible code letters and an explanation of how the process is | using the file are given below: | | c its current directory | | p the parent of its current directory (only when the | file is being used by the system) | | r its root directory | | v process has exec'ed or mmap'ed file | | For block special devices with mounted file systems, all | processes using any file on that device are listed. For | remote resource names, all processes using any file associ- | ated with that remote resource are reported. fuser cannot | use the mount point of the remote resource; it must use the | resource name. For all other types of files (text files, | executables, directories, devices, etc.) only the processes | using that file are reported. | | The process IDs are printed as a single line on the standard | output, separated by SPACE characters and terminated with a | single NEWLINE. All other output is written on standard | error. | | You cannot list processes using a particular file from a | remote resource mounted on your machine. You can only use | the resource name as an argument. | | Any user with permission to read /dev/kmem and /dev/mem can | use fuser. | | Only the super-user can terminate another user's process | |OPTIONS | If more than one group of files are specified, the options | may be respecified for each additional group of files. | | - Cancel the options currently in force. The new set of | options applies to the next group of files. | |Sun Release 4.1| Last change: 30 June 1988 1 | |FUSER(8) MAINTENANCE COMMANDS FUSER(8) | | -k Send SIGKILL signal to each process. Since this option | spawns kills for each process, the kill messages may | not show up immediately (see kill(2V)). As for the location of sources of "ofiles", here is my contribution: I know of three version of ofiles: two available on the SunSpots archive server at rice (including one specifically for SunOS 4.0x, which we use),and one published in comp.sources.unix (ofiles.new, that does not work for us). Here is some info for retrieving these sources: From the SunSpots archives: FTP: Hostname : titan.rice.edu (128.42.1.30) Directory: sun-source Filename : ofiles.shar Filesize : 33998 bytes Filename : ofiles4.0.shar Filesize : 33557 bytes Archive Server Address: archive-server@rice.edu Archive Server Command: send sun-source ofiles.shar or send sun-source ofiles4.0.shar From the uunet archives: Archive Server Address: netlib@uunet.uu.net Archive Server Command: send volume18/ofiles.new from comp.sources.unix Thanks to all contributors! Best regards, Dominique Mr. Dominique Petitpierre |e-mail, preferred: petitp@divsun.unige.ch ISSCO, University of Geneva |UUCP: mcvax!cui!divsun.unige.ch!petitp 54 route des Acacias | CH-1227 GENEVA (Switzerland)| Tel: 0041/22/705 71 17