Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cornell!uw-beaver!rice!sun-spots-request From: rlk@think.com (Robert L. Krawitz) Newsgroups: comp.sys.sun Subject: Re: cron/find sting! SUN OS 3.5 HELP!!! Keywords: SunOS Message-ID: <8903111616.AA17368@regin.think.com> Date: 23 Mar 89 19:48:13 GMT Sender: usenet@rice.edu Organization: Sun-Spots Lines: 28 Approved: Sun-Spots@rice.edu Original-Date: Sat, 11 Mar 89 11:16:15 EST X-Sun-Spots-Digest: Volume 7, Issue 209, message 1 of 13 I suspect that someone on the client is/was using 'on'. If the working directory isn't actually mounted on the machine that 'on' is trying to run on, it will mount it -- in /tmp! Either a problem with on or a long-running command can leave the filesystem mounted for a long while (or of course, if someone's running on right when the find goes off, you'll lose). In any event, it certainly sounds like someone's mounting filesystems in /tmp by whatever means. This isn't necessarily wrong, but your find scripts could be better. Try putting a -xdev in your find script before the rm, like this. It cuts off the find if it tries to cross a filesystem boundary. 15 4 * * * find /usr/preserve/ -xdev -mtime +7 -a -exec rm -f - {} \; 30 4 * * * find /tmp/ -xdev -atime +2 \! -type d -exec rm -f - {} \; 45 4 * * * find /usr/tmp/ -xdev -atime +2 \! -type d -exec rm -f - {} \; We got bitten by this once in 3.x. Turns out that the standard crontab distributed with at least some 3.x systems doesn't have the -xdev. We reported it back to Sun, and I don't know when they fixed it. These automatic find scripts can be awfully dangerous if you have a weird configuration. When I was at Project Athena, a few of us got bitten by a similar problem on private workstations (Microvax II's). ames >>>>>>>>> | Robert Krawitz 245 First St. bloom-beacon > |think!rlk (postmaster) Cambridge, MA 02142 harvard >>>>>> . Thinking Machines Corp. (617)876-1111