Cannot umount /usr filesystem (ALWAYS "busy")

Randy Davis root at ninja.dell.com
Wed Jun 13 05:54:08 AEST 1990


In article <1990Jun12.143450.12453 at pmafire.UUCP> rickf at pmafire.UUCP (rick furniss) writes:
| I,ve found that /usr as a separate file system always has these types of
|problems .  It was designed to be used in the root filesystem originaly
|like /dev/,/tmp /bin & /etc.  Always expected to be mounted.

  That's interesting....  How do you come by this conclusion?  AT&T System V,
all flavors up to release 3.whatever, expects /usr to be a separate filesystem
except in the cases of VERY small drives.  As far as previous versions of
UNIX, they bear very little relation to the present versions so this statement
would have little relevance.

  It is probable that the original poster's problem with being unable to
unmount the /usr filesystem is caused by some process still running that has
its working directory under /usr or has a file open in /usr.  Of course, his
dilemma is finding which one.  An often-overlooked problem is one where an
administrator restarts some deamon, such as /etc/cron, while they are under
/usr in their current working directory.  Since processes inherit certain parts
of the enviroment of the parent, which happens to include the parent's current
working directory, any of these processes that are running when the system
attempts to unmount /usr will be unable to.

| I,m not saying you cannot, or should not use it as a filesystem, but 
|you must allow for programs that are expected to be always available to the
|kernel, or single user system, or that presume they are.

   Precisely why SOME programs, deamons, etc. are stored in the root
partition, such as /bin/sh, as opposed to /usr/bin.  I don't see there being
ANY purpose to a /usr if it wasn't meant to be unmounted...

Randy Davis					UUCP: rjd at ninja.dell.com

-- 



More information about the Comp.unix.i386 mailing list