🚀 go-pugleaf

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@think.com>	245 First St.
bloom-beacon >  |think!rlk	(postmaster)		Cambridge, MA  02142
harvard >>>>>>  .	Thinking Machines Corp.		(617)876-1111