jjd@alexander.bbn.com (James J Dempsey) (12/09/90)
It seems to me that there is a bug in the default root crontab that Sun
distributes with each machine such that it ends up causing a lot of
unnecessary NFS traffic each night.
Each of my SunOS 4.0.3 and SunOS 4.1 systems came with a line in root's
crontab which looks like this:
15 3 * * * find / -name .nfs\* -mtime +7 -exec rm -f {} \; -o -fstype nfs -prune
It seems as if the intent of the "-fstype nfs -prune" is to stop the find
from continuing onto remote systems. However, if you try it you will see
that that clause only works if it comes before the rest of the find
statement. If you change it to look like this it will work as intended:
15 3 * * * find / -fstype nfs -prune -o -name .nfs\* -mtime +7 -exec rm -f {} \;
I discovered the problem when there were problems with a subdirectory on a
remote host each of my suns sent me mail saying that they couldn't "find"
in that directory.
--Jim Dempsey--
jjd@bbn.comray@kea.am.dsir.govt.nz (Ray Brownrigg) (05/10/91)
In article <717@brchh104.bnr.ca> jjd@alexander.bbn.com (James J Dempsey) writes: > Each of my SunOS 4.0.3 and SunOS 4.1 systems came with a line in root's > crontab which looks like this: > > 15 3 * * * find / -name .nfs\* -mtime +7 -exec rm -f {} \; -o -fstype nfs -prune > It seems as if the intent of the "-fstype nfs -prune" is to stop the find > from continuing onto remote systems. However, if you try it you will see > that that clause only works if it comes before the rest of the find > statement. If you change it to look like this it will work as intended: > > 15 3 * * * find / -fstype nfs -prune -o -name .nfs\* -mtime +7 -exec rm -f {} \; I suggest there is still a problem with this crontab entry, which others may have seen. If a system on the network is down, then each time this command runs, it results in a message like: find: can't stat systemname: No such file or directory where systemname is the system which is not available. Generally this is acceptable - apart from a mail message to root, but the real problem is that sometimes the find will hang (or perhaps it goes into a loop), and the whole network becomes very sluggish - to the point where logins which require NFS access (to a home directory say) will not complete. The only way I can fix the system is to log on to another connected network and use root access to issue rsh commands to kill the relevant find processes. (I was sure glad I had the appropriate entries in /.rhosts to be able to do this!). What is this leading up to? Well I believe that an undocumented option to find will alleviate the problem. Certainly the "can't stat" message is no longer issued, and hopefully the hanging no longer occurs also. The -mount option to find appears to restrict the activities of the command to the mounted partition(s) specified in the pathname-list. Thus the other common root crontab entry would be written something like: 15 2 * * * find / /usr /home -mount -name core -atime +1 -exec rm {} \; The mount option seems to be commonly available - I first came across it on an AT&T 3B2 running SVR3.1! A few questions: 1) Has anybody else seen the problems described above? - there did not seem to be any followups to the original message, and I had to scour the archives back to last December to find the above reference. 2) Are there other well known solutions to the "can't stat" annoyance? 3) Any other comments, undocumented features, etc. Ray Brownrigg ray@am.dsir.govt.nz
breynolds@ucsd.edu (Bill Reynolds) (06/05/91)
In article <2802@brchh104.bnr.ca> ray@kea.am.dsir.govt.nz (Ray Brownrigg) writes: > > <Long discussion on bug in crontab distributed by sun deleted> > > A few questions: > 1) Has anybody else seen the problems described above? - there did not > seem to be any followups to the original message, and I had to scour the > archives back to last December to find the above reference. > 2) Are there other well known solutions to the "can't stat" annoyance? > 3) Any other comments, undocumented features, etc. > > Ray Brownrigg ray@am.dsir.govt.nz Yes, we have seen precisely this bug. We had no idea what was causing our fileserver (sun 3/something SunOS4.03) to lock everybody out now and then. After reading this post, I checked roots mbox, and sure enough, there were the "can't stat" mail messages from cron. Thanks for the info - I don't think we would have ever put 2 + 2 together to get this little tidbit. -- _______________________________________________________________________ | Bill Reynolds | bill@inls1.ucsd.edu
ssd@engr.ucf.edu (Steven S. Dick) (06/05/91)
In article <2802@brchh104.bnr.ca> ray@kea.am.dsir.govt.nz (Ray Brownrigg) writes: [stuff deleted] >What is this leading up to? Well I believe that an undocumented option to >find will alleviate the problem. ... >The -mount option to find appears to restrict the activities of the >command to the mounted partition(s) specified in the pathname-list. Thus >the other common root crontab entry would be written something like: > >15 2 * * * find / /usr /home -mount -name core -atime +1 -exec rm {} \; > >The mount option seems to be commonly available - I first came across it >on an AT&T 3B2 running SVR3.1! This sounds an awful lot like the documented -xdev option. Is there any difference? Steve ssd@engr.ucf.edu
jms@tardis.tymnet.com (Joe Smith) (06/05/91)
In article <2802@brchh104.bnr.ca> ray@kea.am.dsir.govt.nz (Ray Brownrigg) writes:
: What is this leading up to? Well I believe that an undocumented option to
: find will alleviate the problem. Certainly the "can't stat" message is no
: longer issued, and hopefully the hanging no longer occurs also.
:
: The -mount option to find appears to restrict the activities of the
: command to the mounted partition(s) specified in the pathname-list. Thus
: the other common root crontab entry would be written something like:
:
: 15 2 * * * find / /usr /home -mount -name core -atime +1 -exec rm {} \;
I have been using -xdev to prevent 'find' from going into mount points.
("-xdev" is documented in the man pages). Therefore I was very curious
as to the difference between the -xdev and -mount options.
Here's what I found:
% df
Filesystem kbytes used avail capacity Mounted on
/dev/sd0a 7855 3071 3998 43% /
/dev/sd0g 172117 142655 12250 92% /usr
/dev/sd0h 352909 288956 28662 91% /export
tardis:/var/spool/mail 61418 40105 15171 73% /var/spool/mail
tardis:/home/tardis 596610 519868 17081 97% /home/tardis
swap 37424 0 37424 0% /tmp
% find / -xdev -print >temp.1
% find / -mount -print >temp.2
% diff temp.1 temp.2
3,4d2
< /export 4.2 mount point
< /usr 4.2 mount point
8d5
< /home/tardis nfs mount point
252d248
< /tmp tmpfs mount point
286d281
< /var/spool/mail nfs mount point
The end result is that -xdev tells 'find' to process mount points as if
the were empty directories. (The directory is visible, but the files
inside it are not.) The -mount option tells 'find' to completely ignore
any mount point not explicitly listed on the command line. (The directory
is invisible.)
--
Joe Smith (408)922-6220 | SMTP: jms@tardis.tymnet.com or jms@gemini.tymnet.com
BT Tymnet Tech Services | UUCP: ...!{ames,pyramid}!oliveb!tymix!tardis!jms
PO Box 49019, MS-C51 | BIX: smithjoe | CA license plate: "POPJ P," (PDP-10)
San Jose, CA 95161-9019 | humorous dislaimer: "My Amiga 3000 speaks for me."