Solved "Locate" command

[Skybear]

I learned about the "locate" command the other day when going through a course in Udemy. But the command didn't work. I'm sure I'm missing something very simple, though.

Here are the terminal commands:

mike@mike-MS-7E26:~/Documents$
mike@mike-MS-7E26:~/Documents$ locate file2.txt
mike@mike-MS-7E26:~/Documents$
mike@mike-MS-7E26:~/Documents$ ls -l
total 2512
-rw-rw-r-- 1 mike mike      41 May 18 07:09  file1.txt
-rw-rw-r-- 1 mike mike      41 May 18 07:13  file2.txt
-rw-rw-r-- 1 mike mike 2563954 May 13 06:47 'Linux commands.odt'
mike@mike-MS-7E26:~/Documents$

I went to a Geeks for Geeks web page this website to see what I was missing but nothing stood out.
https://www.geeksforgeeks.org/linux-unix/locate-command-in-linux-with-examples/

 

[osprey]

I learned about the "locate" command the other day when going through a course in Udemy. But the command didn't work. I'm sure I'm missing something very simple, though.

Here are the terminal commands:

mike@mike-MS-7E26:~/Documents$
mike@mike-MS-7E26:~/Documents$ locate file2.txt
mike@mike-MS-7E26:~/Documents$
mike@mike-MS-7E26:~/Documents$ ls -l
total 2512
-rw-rw-r-- 1 mike mike      41 May 18 07:09  file1.txt
-rw-rw-r-- 1 mike mike      41 May 18 07:13  file2.txt
-rw-rw-r-- 1 mike mike 2563954 May 13 06:47 'Linux commands.odt'
mike@mike-MS-7E26:~/Documents$

I went to a Geeks for Geeks web page this website to see what I was missing but nothing stood out.
https://www.geeksforgeeks.org/linux-unix/locate-command-in-linux-with-examples/

Perhaps the database is not set up. To set it up one can run as root or sudo:

updatedb

After running that command the database should hold the names of all the files and directories and the locate command should be able to access them, and work as intended.

 

[Skybear]

Perhaps the database is not set up. To set it up one can run as root or sudo:

updatedb

After running that command the database should hold the names of all the files and directories and the locate command should be able to access them, and work as intended.

Thanks.

Can you tell me more about the database not being setup in this context? I don’t understand.

 

[osprey]

Thanks.

Can you tell me more about the database not being setup in this context? I don’t understand.

There are a few packages that can run a locate command. There's the locate package, the mlocate package and the plocate package. To see which one is installed in debian based system one can run the following:

[~]$ apt list -i | grep locate
plocate/testing,now 1.1.24-1 amd64 [installed]

On this machine, the installed package is plocate, which provides the locate command and creates the database.

The datebase is a listing of all the files and directories on the system, with some exceptions.The exceptions are described in the configuration file at /etc/updatedb.conf, which looks like this on this machine:

[~]$ cat /etc/updatedb.conf
PRUNE_BIND_MOUNTS="yes"
# PRUNENAMES=".git .bzr .hg .svn"
PRUNEPATHS="/tmp /var/spool /media /var/lib/os-prober /var/lib/ceph /home/.ecryptfs /var/lib/schroot"
PRUNEFS="NFS afs autofs binfmt_misc ceph cgroup cgroup2 cifs coda configfs curlftpfs debugfs devfs devpts devtmpfs ecryptfs ftpfs fuse.ceph fuse.cryfs fuse.encfs fuse.glusterfs fuse.gocryptfs fuse.gvfsd-fuse fuse.mfs fuse.rclone fuse.rozofs fuse.sshfs fusectl fusesmb hugetlbfs iso9660 lustre lustre_lite mfs mqueue ncpfs nfs nfs4 ocfs ocfs2 proc pstore rpc_pipefs securityfs shfs smbfs smb3 sysfs tmpfs tracefs udev udf usbfs"

Certain files are pruned out of the database because they are temporary files or system files that are recreated on each boot and are basically available by other means. It's a configuration file so can be altered to suit different purposes, but for ordinary users, the default is sufficient.

The database for the locate command is usually located at /var/lib, in the case of plocate, at /var/lib/plocate/plocate.db.

The locate database is usually created each day so that it's kept up to date for the user who may be creating new files, deleting files, installing files etc. The daily creation of the database is controlled by a cron job, or a systemd timer unit. The cron job configuration is in the /etc/cron.daily/ directory, in this case in the file: plocate, in that that directory.
In a systemd machine the systemd.timer triggers the systemd unit file to write the database. On this machine systemd controls the locate database in the plocate-updatedb.timer file which shows that the database is created daily, and at a random time between 0 and 1 hour after boot time:

[~]$ systemctl cat plocate-updatedb.timer
# /usr/lib/systemd/system/plocate-updatedb.timer
[Unit]
Description=Update the plocate database daily

[Timer]
OnCalendar=daily
RandomizedDelaySec=1h
AccuracySec=6h
Persistent=true

[Install]
WantedBy=timers.target

To see when it was activated in real time, run a command like:

[~]$ journalctl -b | grep plocate
May 26 07:40:17 min systemd[1]: Started plocate-updatedb.timer - Update the plocate database daily.
May 26 08:17:36 min systemd[1]: Starting plocate-updatedb.service - Update the plocate database...
May 26 08:17:40 min systemd[1]: plocate-updatedb.service: Deactivated successfully.
May 26 08:17:40 min systemd[1]: Finished plocate-updatedb.service - Update the plocate database.
May 26 08:17:40 min systemd[1]: plocate-updatedb.service: Consumed 1.695s CPU time over 3.589s wall clock time, 353M memory peak.

On this machine checking the time when the updatedb command was run shows that the timer was registered to run the update at about 7:40, and that the database was actually written at about 8:17, within the hour the configuration above specified. That 7:40 time is the approximate boot time which can be checked with a command like:

[~]$ journalctl -b | head
May 26 07:40:16 min kernel: Linux version 7.0.9+deb14-amd64 ([email protected]) (x86_64-linux-gnu-gcc-15 (Debian 15.2.0-17) 15.2.0, GNU ld (GNU Binutils for Debian) 2.46) #1 SMP
<snip>

where the time on the first line is basically boot time.

As the list of files and directories on the system changes, the locate database holds the current list at the actual time the database was created. If the database is only created once a day, any alterations to the list of files and directories after the database is created on that day, will not be recorded in the database yet. One can immediately update the database by running the updatedb command as root.

The reason the database would not be present for the user at all, could be because the installation of the locate package hasn't as yet been triggered by the daily cron job or systemd timer to create the database. Hopefully the above info should enable the user to check if the locate system is working.

 

[Skybear]

Thanks Osprey. That's a lot of good information. I'm going to take it slow to make sure I understand each part.

The terminal says that I have plocate. However, there's a warning that I didn't see in your example:

mike@mike-MS-7E26:~$ apt list -i | grep locate

WARNING: apt does not have a stable CLI interface. Use with caution in scripts.

plocate/noble,now 1.1.19-2ubuntu2 amd64 [installed]

 

[deb_user]

Don't worry about that warning. It means nothing in your situation. It just means that using apt in scripts may not produce expected results in some situations. No script, no worries.