Ah, herewith the last few lines:
open("..", O_RDONLY) = 5
fstat64(5, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
fchdir(5) = 0
close(5) = 0
open("mike", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = -1 ENOENT (No
such file or directory)
--- SIGPIPE (Broken pipe) ---
+++ killed by SIGPIPE +++
And I believe I've found the problem! I'm running something called SHFS
(http://shfs.sourceforge.net/) which is able to mount a file system across
SSH. In /home/mike I have a symlink to /mnt/mike which is mounting
/home/mike on a friends computer. I tried to cd /mnt/mike and I got a broken
pipe - it appears that the ssh mount died and wasn't elegantly handling the
chdir into a broken mount point.
I'm going to give the maintainer of SHFS a buzz and let him know about it.
Two questions...
1) How can I exclude /mnt from updatedb (or is it already)
2) The problem appeared to be following the symlink - can I tell updatedb to
not follow symlinks; I don't see why it should as it should index the target
file anyway...
Thank you so much for your assistance Brian and Jon.
-----Original Message-----
From: Brian Ashe [mailto:[EMAIL PROTECTED]
Sent: 18 June 2003 20:36
To: [EMAIL PROTECTED]
Subject: Re[2]: updatedb problem: last try!!
Hello michael,
Wednesday, June 18, 2003, 12:49:17 PM, you textually orated:
mbwc> Thanks for the recommendation, Brian - but I'm not sure that is
mbwc> the case.
mbwc> Filesystem Size Used Avail Use% Mounted on
mbwc> /dev/hda1 9.8G 6.3G 3.0G 68% /
mbwc> /dev/hda2 65G 46G 15G 75% /home
mbwc> none 124M 0 124M 0% /dev/shm
mbwc> I can also cp /var/lib/slocate/slocate.db
mbwc> /var/lib/slocate/slocate.db2/3/4/5/6 etc... Until I'm blue in the
mbwc> face.
mbwc> One thing I was wondering, I was speaking to a friend about this
mbwc> and he suggested removing my slocate database my deleting
mbwc> slocate.db - but in his case it was in a different location. I was
mbwc> wondering if perhaps the last action being taken is slocate is
mbwc> trying to move a file from the wrong location to the wrong
mbwc> location - although the fact that it creates the .tmp file in the
mbwc> correct place doubts this assumption; it's the only thing I can
mbwc> think of right now!
Try stracing it and perhaps only do a small part of the drive by calling
slocate directly...
strace slocate -U /usr/share/icons -o ~/test_sl.db
...and see if A) it completes without error and B) what the output of strace
is if it fails.
If you don't mind spending the time, you could also just do "strace
updatedb".
You should only need the last ~20 lines or so of the output.
Have fun,
--
_________________________________________________________________
Brian Ashe CTO
[EMAIL PROTECTED] Dee-Web Software Services, LLC.
http://www.dee-web.com/
-----------------------------------------------------------------
--
redhat-list mailing list
unsubscribe mailto:[EMAIL PROTECTED]
https://www.redhat.com/mailman/listinfo/redhat-list
--
redhat-list mailing list
unsubscribe mailto:[EMAIL PROTECTED]
https://www.redhat.com/mailman/listinfo/redhat-list
