LinuxQuestions.org - updatedb: not always making slocate find all files.

- Linux - Newbie (https://www.linuxquestions.org/questions/linux-newbie-8/)

- - updatedb: not always making slocate find all files. (https://www.linuxquestions.org/questions/linux-newbie-8/updatedb-not-always-making-slocate-find-all-files-883812/)

updatedb: not always making slocate find all files.

Kernel 2.6.21.5, Slackware 12.0

Hi:

Code:

bash-3.1$ cat /etc/cron.daily/slocate 

#!/bin/sh

/usr/bin/updatedb -c /etc/updatedb.conf

bash-3.1$

This file having been executed day after day, I get

Code:

$ slocate foo

$ /usr/bin/updatedb -c /etc/updatedb.conf

$ slocate foo

/foo1

/foo1/foo

$

Give some more info. Does "foo" always be there, or is a temporary file that could be not present the time updatedb works?
Is updatedb really executed everyday? For instance on a dc server I have that runs slack 12.0 updatedb is executed at about 4 am each day. So your system must be running at the time it is scheduled.

Yes, foo is an old file that has been on disk (hard) for quite a lot.

I do not know what time updatedb is scheduled to run. I can say periodically the disk is scanned. I hear the noise. The period may very well be 24hs.

Take a look at updatedb.conf (if you haven't already). Could the directory containing the file be in PRUNEPATHS list?

I haven't studied slocate that much, but I think I've read that it locates files based on user access. Maybe your user doesn't have read permission for that file?

Quote:

Originally Posted by segmentation_fault (Post 4372499)

Or PRUNEFS, for that matter ... for all we know it (foo) might be
an external HDD using NTFS ...

Cheers,
Tink

Quote:

Originally Posted by segmentation_fault (Post 4372499)

Code:

bash-3.1$ cat /etc/updatedb.conf 

PRUNEFS="devpts NFS nfs afs proc smbfs autofs iso9660 udf"

PRUNEPATHS="/dev /proc /sys /tmp /usr/tmp /var/tmp /afs /net" 

export PRUNEFS

export PRUNEPATHS

bash-3.1$

From here, I infer the strings PRUNEFS and PRUNEPATHS are variable names. However slocate and updatedb manuals call them options [?!]. Assuming they are environment variables, they are unset or empty, as the set command reveals.

And definitely, in this case, it is not a matter of access rights because, as you can see in post #1, the second invocation of slocate brings 'foo' out.

Quote:

Originally Posted by Tinkster (Post 4372543)

Or PRUNEFS, for that matter ... for all we know it (foo) might be
an external HDD using NTFS ...

Again, never mind the drive location or file system: second invocation works fine. But, in case my logic is faulty, here are some data (NOTE: usb-in-a-nutshell.pdf is here old foo in post #1):

(a) Only one user account in the system besides root: semoi. Slocate run as, and manual invocation of updatedb made as root (BUT WHO IS the user executing the script /etc/cron.daily/slocate?).

Code:

drwxr-xr-x 39 semoi users 16384 /xp

drwxr-xr-x 3 semoi users 16384  /xp/DIGITALES III/

-rwxr-xr-x 1 semoi users 179330 /xp/DIGITALES III/usb-in-a-nutshell.pdf

(b)

Code:

bash-3.1# mount

[..............] (brackets are mine).

/dev/hda1 on /xp type vfat (rw,uid=1000,gid=100)

/dev/hdb2 on /sma type vfat (rw)

bash-3.1#

It's been a long time since I touched /etc/fstab the last time.

(c) After last automatic execution of update (cron.daily) but before manual execution (see post #1), everything in /sma got located by slocate but, as to /xp, only files in the first two levels of the /xp tree had their names printed. E.g.,

Code:

$ locate DIGITA

/xp/DIGITALES III

# locate nutshell

#

whereas after manually running slocate:

Code:

bash-3.1# locate nutshell                                          

/xp/DIGITALES III/usb-in-a-nutshell.pdf

bash-3.1#

As I pointed out before, usb-in-a-nutshell.pdf has been in /xp/DIGITALES III/ from time immemorial.
Regards and thanks for the feedback.

AFAIK the cron job runs as the user whose crontab contains it. No matter, slocate takes the privilleges of the user that invoked it (slocate, not updatedb) and searches for files that the user has read access. But this doesn't seem to be the case... I assume the uid of semoi is 1000 ?

Quote:

Originally Posted by segmentation_fault (Post 4372951)

... No matter, slocate takes the privilleges of the user that invoked it (slocate, not updatedb) and searches for files that the user has read access. But this doesn't seem to be the case...

I understand. For the file in question, group 'users' has read access granted as well as all other groups:

Code:

-rwxr-xr-x 1 semoi users /xp/DIGITALES III/usb-in-a-nutshell.pdf

And the same happens for all parent directories:

Code:

drwxr-xr-x 39 semoi users 16384 /xp

drwxr-xr-x 3 semoi users 16384  /xp/DIGITALES III/

Hence, root has read access over that file.

Quote:

Originally Posted by segmentation_fault (Post 4372951)

I assume the uid of semoi is 1000 ?

From /etc/passwd:

Code:

semoi:x:1000:100::/home/semoi:/usr/bin/bash

/dev/hda1, mounted on /xp, is FAT32. In this file system there is no provision for files access rights or ownership. After linux mounts it, all files are seen this way:

Code:

drwxr-xr-x 2 root root 2048 2003-11-04 16:20 z

I, usually being semoi, and many times inside the GUI, find it uncomfortable to write files to /xp, all its subdirs being owned by root. This is why I used options uid=, gid= in fstab. With fstab thus modified, all files in /xp look as owned by semoi to the O.S.

This having been said, the fact mentioned in post #6, point (c), about slocate only finding files in the first and second level of the /xp hierarchy, I find it very hard to understand. Ought something in my linux box, besides slocate's behavior, not be wrong? Thanks for your answer.