Path: utzoo!utgpu!utstat!jarvis.csri.toronto.edu!mailrus!cornell!uw-beaver!rice!sun-spots-request From: iotek!mike@uunet.uu.net (Mike Thompson) Newsgroups: comp.sys.sun Subject: cron/find sting! SUN OS 3.5 HELP!!! Keywords: SunOS Message-ID: <298@jupiter.iotek.UUCP> Date: 11 Mar 89 01:02:27 GMT Sender: usenet@rice.edu Organization: IOTEK Inc Lines: 57 Approved: Sun-Spots@rice.edu Original-Date: 1 Mar 89 23:51:10 GMT X-Sun-Spots-Digest: Volume 7, Issue 192, message 8 of 9 FORGROUND: (See BACKGROUND below for info on the organization of our system) I came in this morning and discovered that every file that hadn't been accessed in the past 2 days on /usr/mercury had been deleted (none of the other file systems had been modified in this way. By examining the lastcomm file I discovered on one of the clients "rm"s (hundreds of them) starting at 4:30am and running through to 4:58am followed by a find with about 300 CPU seconds time, the find had started at 4:30am, it was the only find run by root at or around 4:30am. In every system's crontab file are the following three lines: 15 4 * * * find /usr/preserve/ -mtime +7 -a -exec rm -f - {} \; 30 4 * * * find /tmp/ -atime +2 \! -type d -exec rm -f - {} \; 45 4 * * * find /usr/tmp/ -atime +2 \! -type d -exec rm -f - {} \; All systems run the same version of cron and find, none of the other systems exhibited this, all their 4:30 finds executed in under a CPU second as is to be expected. /tmp is not a symbolic link. I suspect that there is some kind of bug in cron altho it could be anything from a virus or a malicious user to a bad block on the swap partition. Help!!!, I've managed to recover the files but I don't want it to happen again, has anyone encountered this before, does anyone know what is going on???????? Thanks in advance. I am also going to call sun software support to see if they can help. BACKGROUND: We are running 1 diskfull SUN 3/60 and 4 diskless SUN 3/50's here with OS 3.5. File systems are arranged thus: ON THE SERVER Filesystem kbytes used avail capacity Mounted on /dev/sd0a 7608 5000 1847 73% / /dev/sd0f 7855 3800 3269 54% /pub.MC68020 /dev/sd0h 77025 56997 12325 82% /usr.MC68020 /dev/sd2h 188292 116019 53443 68% /usr.MC68020/mercury /dev/sd0d 89461 52574 27940 65% /usr.MC68020/mercury/scratch /dev/sd2g 53308 20545 27432 43% /usr.MC68020/mercury/spool /dev/sd2a 9693 5088 3635 58% /broot ON THE CLIENT's Filesystem kbytes used avail capacity Mounted on /dev/nd0 7608 2196 4651 32% / /dev/ndp1 7855 3800 3269 54% /pub (ro) mercury:/usr.MC68020 77025 56997 12325 82% /usr (ro) mercury:/usr/mercury 188292 116019 53443 68% /usr/mercury mercury:/usr/mercury/scratch 89461 52574 27940 65% /usr/mercury/scratch mercury:/usr/mercury/spool 53308 20545 27432 43% /usr/mercury/spool -- Michael A. Thompson, Iotek Inc, E-Mail: mike@iotek.uucp 1127 Barrington St., Suite 100, Fax: (902)420-0674 Halifax, N.S., B3H 2P8, Canada Phone: (902)420-1890