Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!cs.utexas.edu!uunet!sci34hub!gary From: gary@sci34hub.UUCP (Gary Heston) Newsgroups: comp.unix.i386 Subject: Re: Cannot umount /usr filesystem (ALWAYS "busy") Message-ID: <648@sci34hub.UUCP> Date: 12 Jun 90 15:58:08 GMT References: <267@jorel.UUCP> Reply-To: gary@sci34hub.sci.com (Gary Heston) Distribution: usa Organization: SCI Technology, Inc., Huntsville, Al. Lines: 30 In article 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!!)