🚀 go-pugleaf

In article <3vl6kn$is2@explorer.csc.com>, Steven Allen <sallen@csc.com> wrote:
>	Does anybody know why I keep getting the following error
>when cron runs updatedb?   
>	Find: /proc/self/fd/4  No such file or directory
>Now, being the master of the obvious that I am....I know that this
>"thing" does not exist on my machine.....is there a bug fix that I
>missed somewhere on the road?  

Interesting ...

The /proc "file system" is a pseudo-file system wherein you can find
information about processes.  The /proc/self "directory" contains
information about whatever process looks inside it - in this case,
"find".  (Would that we humans had such an introspective device!)  The
/proc/self/fd "directory" contains information about the different file
descriptors used by the examining process.  Each "file" in that
directory - named 0, 1, 2, etc. - is a "symbolic link", where the
symbol contained is not a file path name, but is instead a pointer to
device number (major/minor) + (inum or other info).

Now, why did you think that /proc/self/fd/4 didn't exist?  Obviously,
because when you looked, it wasn't there!  Try the following, and see
what happens:

	$ ls -l /proc/self/fd 4< /dev/null

This opens /dev/null on file descriptor 4 (if your shell has this
capability), and then runs the 'ls'.  You'll see it.

So, what was happening to the 'find'?  When 'find' gets to a directory,
it will read it to find what entries are in it.  If the directory is
short enough, it closes the directory.  While the directory is open,
the /proc/self/fd/4 entry is there.  With it closed, it's gone.

How to fix this?  There are a couple of lines in /usr/bin/updatedb
where the arguments to 'find' include:
	-fstype nfs -o ... -prune
Perhaps you should add "-fstype proc -o ..." to this.

Alternately, earlier in the script, there is a line:
	: ${PRUNEPATHS="/tmp /usr/tmp /var/tmp /afs"}
Perhaps you should add "/proc" to this line.

Either will work.  Which you do depends on how likely you think that
the concepts of /proc and the proc file system are separable.

Whichever you do, remember: do NOT just go into the 'updatedb' script
with a slash-and-burn editing job, so that you forget what it looked
like before and can't fix it if you learn that what I'm saying doesn't
match your version.  First, use RCS 'ci' to check it into an RCS
archive in an appropriate subdirectory of /usr/src/.  (You may have to
make the appropriate subdirectory.)  Then check it out again with 'co',
make the change, and remember to save the change using 'ci' again.  NOW
you can copy the changed script back to /usr/bin/updatedb.

Of course, what I've described are generic rules for modifying any
script.  Forgive me if they're obvious to you; but I've seen a lot of
people get burned from not carefully tracking modifications they make
to files, especially to shell scripts that are in use.

-- 
Joe Yao				jsdy@cais.com - Joseph S. D. Yao