🚀 go-pugleaf

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