bernie@metapro.DIALix.oz.au (Bernd Felsche) (06/28/91)
In <1991Jun23.065836.15692@metapro.DIALix.oz.au> I wrote: >Has anybody else noticed the occasional loss of /lost+found under SCO Unix? >There are only two people who can remove the thing, and we haven't. >Any clues? >(I'm running a cron task to check for lost+found on all >mounted file systems at 3 hour intervals, to make sure we >have somewhere to put lost files in case of a crash) I have received responses from: Roger Cornelius <rac@sherpa.UUCP> Pat Myrto <pat@rwing> Judy Scheltema <judy@lobster.hou.tx.us> Ted Chan <ys2!twc@murtoa.cs.mu.oz.au> Jay Vassos-Libove <libove@libove.det.dec.com> Many thanks for your interest and clues. The first item contains the most extensive solution. Here's the summary: From: Roger Corneliussherpa!rac <sherpa!rac%murtoa.cs.mu.oz@uunet.uu.net> If you're using 3.2.0, there was a bug in the /etc/cleanup script which did this. It has been fixed in 3.2.2. I no longer have a copy of the script that had the problem, but look for the find which searches through lost+found. If I remember correctly, it was something like: find /lost+found -mtime +21 -exec rm -rf {} \; >/dev/null 2>&1 Notice the rm -rf. The following is the code I replaced it with. The important thing is to get rid of the -r option to rm. # clean up all mounted lost+found directories filesystems=`/etc/mount|sed 's/[ ].*//'` for mount in filesystems do find $mount/lost+found -mtime +21 -exec rm -f {} \; >/dev/null 2>&1 done --------------- From: rwing!pat <rwing!pat%murtoa.cs.mu.oz@uunet.uu.net> I don't run SCO, but ISC, and I had a similar problem. The cause was root via cron is removing it, via a line in /etc/cleanup, that goes something like find /lost+found +mtime +14 -exec rm -rf {} \; Note the 'r' in the rm command, meant to clean up any subdirs put in lost+found. Unfortunately, it also removes /lost+found. A check for existance of lost+found should be done, then a cd to it, then do a find on the current subdir, or safer yet, remove the r from the rm command, and check it yourself periodially. Note the test for lost+found is CRITICAL if you use the cd to lost+found option and keep the 'r' in the rm command, else if the cd ails, the rm -rf will be running on the *root* subdir, thus wiping out the WHOLE FILESYSTEM. So, to be safe, I just changed mine to be find /lost+found +mtime +14 -exec rm -f {} \; no 'r' ---^ and will deal with reconnected subdirs manually. Its much less apt to have catastrophic results if something ELSE wipes out /lost+found. The cleanup is only done on root's lost+found anyway, so it could probably be omitted with virtually no ill effect, since lost+found subdirs on other filesystems do not get automatically cleaned. Check it out, that is probably the cause.... --------------- From: Judy Scheltema <judy@lobster.hou.tx.us> Yes, same here. But like you, I have no clues as to why it is happening. We are running 2.3.2 if that makes any difference. If you find out why this is happening, I would appreciate it if you would let me know, or if there's enough interest, post it to the net. --------------- From: Ted Chan <ys2!twc@murtoa.cs.mu.oz.au> FYI Esix Rev C occasionally lost /lost+found (but none of the mounted file system lost+found directories). The Rev D update of Esix seems to have fixed this (though I switched to the FFS, so that makes the latter statement speculative, at best...). Anyway, you might try to contact SCO to see if they have a fix. This problem may have come from the AT&T port base. From: Jay Vassos-Libove <libove@libove.det.dec.com> Look in the regularly run stuff - either in the boot up (rc) files or in the cron stuff. One of the standard system procedures is set up wrong - it is supposed to clean old stuff out of /lost+found directories but it actually looks more like: find /lost+found -mtime +NN -exec /bin/rm -rf {} \; which of course will throw out the baby (lost+found directory) with the bathwater (the old lost+found files in the directory) if nothing ever gets touched in lost+found for NN days. --------------- That's all. For now, I've modified the "find" in /etc/cleanup to only look for files, and have removed the "r" option from "rm". Thanks again to all who responded -- Bernd Felsche, _--_|\ #include <std/disclaimer.h> Metapro Systems, / sold \ Fax: +61 9 472 3337 328 Albany Highway, \_.--._/ Phone: +61 9 362 9355 Victoria Park, Western Australia v Email: bernie@metapro.DIALix.oz.au