cron/find sting! SUN OS 3.5 HELP!!!
Robert L. Krawitz
rlk at think.com
Fri Mar 24 05:48:13 AEST 1989
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 <rlk at think.com> 245 First St.
bloom-beacon > |think!rlk (postmaster) Cambridge, MA 02142
harvard >>>>>> . Thinking Machines Corp. (617)876-1111
More information about the Comp.sys.sun
mailing list