Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!elroy.jpl.nasa.gov!sdd.hp.com!spool.mu.edu!news.cs.indiana.edu!msi.umn.edu!noc.MR.NET!gacvx2.gac.edu!gacvx2.gac.edu!scott From: scott@erick.gac.edu (Scott Hess) Newsgroups: comp.sys.next Subject: Re: OD thrashing on 2.0 software Message-ID: Date: 12 Feb 91 03:27:09 GMT References: <1991Feb11.201046.12640@athena.mit.edu> Organization: Gustavus Adolphus College Lines: 51 Nntp-Posting-Host: erick.gac.edu In-reply-to: shanega@athena.mit.edu's message of 11 Feb 91 20:10:46 GMTLines: 51 In article <1991Feb11.201046.12640@athena.mit.edu> shanega@athena.mit.edu (Shane G. Artis) writes: and the OD could no longer be dismounted. This is NOT due to a problem with the optical disk drive, and is, in fact, normal behavior (though undesirable). I had the same problem on my '030 cube and traced it to a daily administration task which searches (using 'find') for files suffixed '.nfs' and clears them. It should (I think) search just the boot disk, but unfortunately it also searches the mounted optical disk. If you are a standalone system, I recommend logging in as root and removing the last line of the /usr/adm/daily file (make a backup of course). This is the source of the problem. This is correct. The script only executes at about 2am, though, or at least when it's executed in my experience. [Story - this summer, one of my roomates and I were in working late at night, this in a building with lots of NeXTs (well, it was actually at NeXT, but that's incidental). We're working along, working along, then at 2am our machines go berserk. This was quite noticable, as we both had two machines in "our" offices, and there were of course many machines up and down the way. Scary! ] Anyhow, rather than delete that line in the /usr/adm/daily file, comment it out by inserting a '#' character at the beginning of it. Also, you might want to put a little remark (again commented by # signs) to indicate why you did this, in case you later need to revert (and are no longer sure exactly what happened). Another option would be to move the line to /usr/adm/weekly. That would cut execution to once a week. This is just a quick and dirty fix, and may cause problems on networked machines. Talk to your administrator. Anyone have a real fix - i.e., does 'find' have an option that prevents recursive searches of mounted file systems or some such thing? Well, I suppose that could be done. I'm not sure how. The script itself uses '-fstype nfs -prune' to stop searches at nfs mount-points. The -xdev option is supposed to cause find not to traverse to a filesystem different from the one on which the current argument resides. Maybe: find / -xdev -name .nfs\* -mtime +7 -exec rm -f {} \; -o -fstype nfs -prune would be better (tell me if this works!). -- scott hess scott@gac.edu Independent NeXT Developer GAC Undergrad "Tried anarchy, once. Found it had too many constraints . . ." "Buy `Sweat 'n wit '2 Live Crew'`, a new weight loss program by Richard Simmons . . ."