jmcook@jorel.UUCP (joel m. cook) (06/08/90)
For the past few weeks I have been unable to take the system into single user mode (telinit s or telinit 1) or even to shutdown without scragging /usr because when the attempt is made by either the system or I to unmount it, it's always "busy". I have used telinit s and then attempted to maually unmount it, but no luck. Using ps to see what's busy has been no use, and fuser reports no files in use on /dev/dsk/1s3, which is the device/partition it's on. I first noticed the problem a few weeks ago after massive damage to the root filesystem caused by bad memory-induced "PANIC's". Now, I am unable to unmount /usr, which means that any shutdown results in fsck being invoked etc. Any help will be much appreciated, e.g., is there a problem with /usr being on the second disk (don't see why)? how can I find out (since fuser gives no help) why umount thinks it's busy? Thanks for any pointers in the right direction! -- Joel M. Cook jmcook@jorel.apldmt.com "...20 years of schoolin' and they put you on the day shift..."
cpcahil@virtech.uucp (Conor P. Cahill) (06/09/90)
First off, when you ask for help, don't do: > Followup-To: poster It gets people mad when inews refuses to place the article into the newsgroup "poster". They may not take the time to go back and fix it. If you would prefer an email response, specify so at the end of your posting and most people will adhere to it (unless they think it is a subject that many people would be interested in). In article <267@jorel.UUCP> jmcook@jorel.UUCP (joel m. cook) writes: [ problem of /usr not being unmounted deleted ] >Any help will be much appreciated, e.g., is there a problem with /usr >being on the second disk (don't see why)? how can I find out (since >fuser gives no help) why umount thinks it's busy? 1. What does ps -ef say (i.e. what processes are running)? 2. Do you have any other file systems mounted on top of /usr? 3. Are you sure that you are not in /usr I don't think fuser is *guaranteed* to find every process on the file system (it does do a pretty good job though). I seem to recall some situations where fuser didn't find processes on the file system. -- Conor P. Cahill (703)430-9247 Virtual Technologies, Inc., uunet!virtech!cpcahil 46030 Manekin Plaza, Suite 160 Sterling, VA 22170
drich@dialogic.com (Dan Rich) (06/11/90)
I have run into this problem myself, and have gone through all of the obvious solutions. I have checked for processes with both fuser, and ps. But, I did have an idea late last night that I haven't had the time to check on yet. Is it possible that the accounting package still has files open in /usr? If so, does anyone know of a way to stop the accounting to prevent this? I assume I would just need to create a "kill" script in /etc/rc0.d with the /usr/lib/acct/shutacct command (or just copy /usr/lib/acct/shutacct to /etc/rc0.d/S??acct). Any comments? -- Dan Rich | drich@dialogic.com || ...!uunet!dialogic!drich UNIX Systems Administrator | "Danger, you haven't seen the last of me!" Dialogic Corporation | "No, but the first of you turns my stomach!" (201) 334-1268 x213 | -- The Firesign Theatre's Nick Danger
cpcahil@virtech.uucp (Conor P. Cahill) (06/12/90)
In article <DRICH.90Jun11105134@junkbox.dialogic.com> drich@dialogic.com (Dan Rich) writes: >Is it possible that the accounting package still has files open in >/usr? If so, does anyone know of a way to stop the accounting to >prevent this? I assume I would just need to create a "kill" script in >/etc/rc0.d with the /usr/lib/acct/shutacct command (or just copy >/usr/lib/acct/shutacct to /etc/rc0.d/S??acct). Any comments? This should be handled with /etc/rc0.d/K90acct (at least it is on my system - I don't recall doing anything special to add it there). -- Conor P. Cahill (703)430-9247 Virtual Technologies, Inc., uunet!virtech!cpcahil 46030 Manekin Plaza, Suite 160 Sterling, VA 22170
rickf@pmafire.UUCP (rick furniss) (06/12/90)
Check for sticky bit programs, such as sh & csh them selfs. 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. 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. **** Standard Disclaimer **** Rick Furniss
gary@sci34hub.UUCP (Gary Heston) (06/12/90)
In article <DRICH.90Jun11105134@junkbox.dialogic.com> drich@dialogic.com (Dan Rich) writes: >Is it possible that the accounting package still has files open in >/usr? If so, does anyone know of a way to stop the accounting to >prevent this? I assume I would just need to create a "kill" script in >/etc/rc0.d with the /usr/lib/acct/shutacct command (or just copy >/usr/lib/acct/shutacct to /etc/rc0.d/S??acct). Any comments? It's possible that acct is running; look in /etc/rc2.d for an entry of the form S22acct linked to a script in /etc/init.d. If you find it, rename it to K22acct and accounting will not be enabled upon your next reboot. Regarding /usr being busy.... Several things work in /usr/spool during multiuser mode (init 2 or above) that can cause this; the print spooler, cron, and uucp come to mind. Cron also writes to a log file /usr/lib/cron/log periodically. Mounting and umounting /usr is (in my experience) only possible in single user mode. By the way, under ISC stuff, the accounting files and cron log grow forever. Amazing how much space they can take up; accounting is turned off on all the systems I deal with. -- Gary Heston { uunet!sci34hub!gary } System Mismanager SCI Technology, Inc. OEM Products Department (i.e., computers) "I think, therefore, !PANIC! illegal protected mode access attempt Memory fault: core dumped (Just installed rn--testing!!)
root@ninja.dell.com (Randy Davis) (06/13/90)
In article <1990Jun12.143450.12453@pmafire.UUCP> rickf@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@ninja.dell.com --
root@ninja.dell.com (Randy Davis) (06/14/90)
In article <1990Jun13.184338.26482@pmafire.UUCP> rickf@pmafire.UUCP (rick furniss) writes: |[experience in UNIX for 10 years] Interesting... UNIX was not available on the machines you mention until early to mid 1980s. The first one *I* saw was a Plexus in 1983. | Name ONE or more Unix versions that install /usr as MOUNTABLE ?? ALL stock AT&T versions as used on their 3B* series of computers from release 2 and release 3 of System V, all AT&T licensed versions of 3.x I have seen, which includes ISC's and a few others. Since UNIX was written by AT&T (or employees therof :-) as an operating system for use on larger systems on the order of mainframes and minicomputers, your experience in desktops computers does not really apply to the *origins* of UNIX, since UNIX was not originally designed for use on such. If you don't beleive the references I cite above, the *name* itself is a clue, as /usr was where user support programs, etc.. was stored and was by definition not required for basic operation of the operating system. Hence the reason for single-user mode and the fact that /usr was not mounted in the normal single-user mode that early machines booted into by default (back when the machines were of considerable size and usually had physical security). | I,ve never seen this as an option either, though I have seen additional |/u, /user ,/users partitions at install time. What Version, source do you |state does this ? Every one I know has had to install first, then re-partition |to get /usr as a mountable FS. The wording here is a bit unclear to me. All versions I have EVER installed normally set up the /usr partition as a separate, mounted filesystem outside of /. The only exception I have seen to this is certain versions designed for the 386 and smaller machines (most notably Dell UNIX 1.1) that detects the use of a small hard drive, I think the change-over point is 40 MB, and defaults to no separate /usr partition. Versions? AT&T System V Release 2, 2.1, 3.0, 3.1, 3.1.1, 3.2 in particular, and I believe I remember working on a few release 1 machines also - in which case the /usr filesystem was mounted on those also (or I would have remembered it, since it is not common for it to be integral to root, at least in the minicomputer enviroment). | My experience installing Unix is limited to Xenix & AT&T Unix derivitives |for Intel, Tandy & Plexus machines. Plexus had the first ATT source license |as far as I know. Probably, as I remember a Plexus in the Lab when I first started working for AT&T in 1983. I think the key difference between yours and my experiences are the size of machines. I started on mini's such as the AT&T 3B2, 3B5, 3B15, and 3B20; where the hard disk size was normally a lot greater (read: almost always MUCH greater) than you found on any PC or home machine of the same time. By your statement above, your experience is primarily on microcomputers, which UNIX was NOT ORIGINALLY designed for. Hence, the reason I tend to doubt your assertions of the origins and original designs of UNIX. | Be it by design or what ever, using /usr as a non-root filesystem will |create some problems that need to be addressed. I would agree that this is so, had /usr not originally been designed to be a mounted filesystem. Since /usr WAS ORIGINALLY ALWAYS a separately mounted filesystem, this issue was already addressed in the ORIGINAL DESIGN. I AGREE that some person who expects them to always be the same filesystem could have since screwed up the works, but that does not change the original design of the /usr filesystem, which is the reason for this debate. | I stand by my guns, /usr was never originaly designed as a non-root FS. And I say you don't know what you are talking about. | /dev, /usr, /etc, /tmp, /bin, /lib, are all considered Unix structure |filesystem directories. Either utilities, or kernel should be able to |count on these being available at all times in multiuser states. AHA!!! TRUE. In *multiuser* states, you are correct... What about in *single* user states, which is what UNIX originally booted into?? Originally, UNIX machines ALWAYS booted into single-user, requiring a system administrator to perform filesystem cleanup, etc.. by hand, THEN change init levels to multi-user. The UNIX autoboot procedure is a relatively new addition to UNIX - in the last seven years (in its 20-year life so far). I believe Plexus was the first with a semi-automated boot procedure, yet every Plexus I saw was a single user machine, so this really doesn't apply. | SU, or single user modes have minimal requirments so that multiuser mode |can be configured, fixed, or made ready. True. | If anyone can dispute this, please correct me with some history/facts. Just check into ANY release from AT&T (the originator of UNIX).... Perhaps you need to provide some facts from a little further back than the microcomputer age of UNIX, since micros able to run UNIX are a little too recent to provide ANY clue as to the origins of UNIX. It really doesn't matter to me... I *know* I am correct, and if you *know* you are correct, we can just go our separate ways thinking the other doesn't have a clue as to what they are talking about. But, from the machines you've listed above, I would say that you need to delve a little further... Randy Davis UUCP: rjd@ninja.dell.com --
cpcahil@virtech.uucp (Conor P. Cahill) (06/14/90)
In article <1990Jun13.184338.26482@pmafire.UUCP> rickf@pmafire.UUCP (rick furniss) writes: > > Be it by design or what ever, using /usr as a non-root filesystem will >create some problems that need to be addressed. I hate to burst your bubble, but root has always been designed to be very small and include only thos programs that are needed to get the system running. This did not include things on /usr. /usr was and is, on many systems, a mounted file system. My first experience with a combined root/usr was with pc based unix systems. > I stand by my guns, /usr was never originaly designed as a non-root FS. Yes it was. your experience with xenix and at&t unix (not sure what you mean by at&t unix) is not representative of the entire unix market. I have worked on Version 6, PWB, System III, System V.* and the vast majority of systems have a /usr partition that is not part of root. > SU, or single user modes have minimal requirments so that multiuser mode >can be configured, fixed, or made ready. That is why /usr is not needed. > Over the years as Unix become widely used, & heavely loaded, /usr started >to become overloaded creating a root FS that was too large for speed / Inode >reasons. Most people took two routes to unload the burden from /usr. If you had worked in an OS shop you would know that whenever a new command is to be added to the system a conscious decision has to be made as to whether or not it is needed on /. The "test" as to whether it is needed on root is usually "do I need it in single user mode?". >(1) Create a second /user, /u, /users partition leaving /usr for > system programs & users. >(2) Made /usr a mountable seperate FS The breakup of a system into filesystems has many other reasons including the ease of administration, separation of different groups of users, ease of backing up separate file systems (especially when dd copies of file systems was the standard mechanism for backup/restore). -- Conor P. Cahill (703)430-9247 Virtual Technologies, Inc., uunet!virtech!cpcahil 46030 Manekin Plaza, Suite 160 Sterling, VA 22170
ron@rdk386.uucp (Ron Kuris) (06/15/90)
In article <267@jorel.UUCP> jmcook@jorel.UUCP (joel m. cook) writes: >Thanks for any pointers in the right direction! Lets start with that first -- don't put "Followup-To: poster"! >For the past few weeks I have been unable to take the system into >single user mode (telinit s or telinit 1) >or even to shutdown without scragging /usr because when the attempt is made >by either the system or I to unmount it, >it's always "busy". > [...] You can use crash if you have it to examine the open file table. This is basically what umount does (I think). Look for files with the dev/inum pair on the device that you are trying to unmount. -- ...!pyramid!unify!rdk386!ron -or- ...!ames!pacbell!sactoh0!siva!rdk386!ron It's not how many mistakes you make, its how quickly you recover from them.
chip@tct.uucp (Chip Salzenberg) (06/15/90)
According to rickf@pmafire.UUCP (rick furniss): >If I recall correctly Unix was originally written on a PDP7, then to PDP11, >[...] These machines hardly had what one would consider large hard >disks, and I believe still, /usr was part of root, the only partition. Sorry -- you didn't beat the reaper. The whole POINT of /usr/bin is that the root filesystem's /bin didn't have room for all the Unix binaries. Why else would there even BE a /usr/bin, /usr/include, /usr/lib, etc? The division between /bin and /usr/bin and between /lib and /usr/lib would not have been worth the trouble if everything fit in the root filesystem. AT&T Unix from V7 (at least) mounts /usr. Some others mount /u. -- Chip Salzenberg at ComDev/TCT <chip@tct.uucp>, <uunet!ateng!tct!chip>
brad@harper.UUCP (Brad Cleghorn) (06/22/90)
drich@dialogic.com (Dan Rich) writes: >I have run into this problem myself, and have gone through all of the >obvious solutions. I have checked for processes with both fuser, and >ps. But, I did have an idea late last night that I haven't had the >time to check on yet. I have found that if my home dir is in /usr, and I'm logged in, (no matter *what* my pwd is) /usr won't umount -- Even if I'm su. I had to log in on the console port as root.
gary@sci34hub.UUCP (Gary Heston) (06/30/90)
In article <248@harper.UUCP> brad@harper.UUCP (Brad Cleghorn) writes: >I have found that if my home dir is in /usr, and I'm logged in, (no >matter *what* my pwd is) /usr won't umount -- Even if I'm su. I had >to log in on the console port as root. Yes, any logged-in users' home directory is considered "open", and the filesystem is therefore busy. This applies to daemon processes as well, like "lp", "cron", and "uucp". If you have any of those running, /usr will refuse to umount for the same reason. Create a file structure /u, add a userid into it, and log in under it. Then try to umount it, even as root--it won't. You can umount /usr as root because roots' home directory is "/", so /usr doesn't have any "open" files or directories. -- Gary Heston { uunet!sci34hub!gary } System Mismanager SCI Technology, Inc. OEM Products Department (i.e., computers) "The esteemed gentleman says I called him a liar. That's true, and I regret it." Retief, a character created by Keith Laumer.
cpcahil@virtech.uucp (Conor P. Cahill) (06/30/90)
In article <681@sci34hub.UUCP> gary@sci34hub.sci.com (Gary Heston) writes: >In article <248@harper.UUCP> brad@harper.UUCP (Brad Cleghorn) writes: >>I have found that if my home dir is in /usr, and I'm logged in, (no >>matter *what* my pwd is) /usr won't umount -- Even if I'm su. I had >>to log in on the console port as root. > >Yes, any logged-in users' home directory is considered "open", and the >filesystem is therefore busy. No. This is not true. Only directories that are active (i.e. current directories of processes) are considered open. Once you cd to another file system, you are no longer tying up the original file system. For example: login in as user a on /a_filesys/a cd / su umount /a_filesys should work unless there is another process that has /a_filesys open. If you are using a shell that has a file based history mechanism (like ksh) then the shell can be the culprit if the history file is in the login directory. If you change the su line to "exec su" then that problem would be solved. >Create a file structure /u, add a userid into it, and log in under it. >Then try to umount it, even as root--it won't. You can umount /usr as >root because roots' home directory is "/", so /usr doesn't have any >"open" files or directories. The "home directory" has nothing to do with it. Current directories, open files, and/or running executables are what matters. -- Conor P. Cahill (703)430-9247 Virtual Technologies, Inc., uunet!virtech!cpcahil 46030 Manekin Plaza, Suite 160 Sterling, VA 22170