Where is /etc/updatedb.conf used on fedora 32?

Ask Fedora
1

Hello,
I’m using fedora 32 and have installed mlocate-0.26-25.fc32.x86_64. Part of that package is the file /etc/updatedb.conf and I think the updatedb program is run from /usr/libexec/mlocate-run-updatedb
(default). I removed nfs from the file /etc/updatedb.conf to have nfs mount(s) also indexed but that doesn’t work, nfs mounts are still ignored probably because in /usr/libexec/mlocate-run-updatedb updatedb.conf is not used. Is /etc/updatedb.conf actually used anywhere?

1 Like
2

Hi rele
you might be running afoul of additional filtering rules.
Firstly, are your NFS shares mounted somewhere in the paths listed in the PRUNEPATHS variable in /etc/updatedb.conf? Because many common mountpoints like /mnt and /net are excluded by that directive.

Secondly, I’m not sure, but NFS shares could additionally be excluded by the /usr/libexec/mlocate-run-updatedb script itself. Could you post the output of

grep nfs /proc/filesystems

?

1 Like
3

Hi @rele, welcome to the community! Please take a minute to go through the introductory post in the #start-here category if you’ve not had a chance to do so yet. It includes information on how to use the forum effectively.

To answer your question, yes /etc/updatedb.conf is the configuration file that affects updatedb. The systemd timer, /usr/lib/systemd/system/mlocate-updatedb.timer, triggers the service /usr/lib/systemd/system/mlocate-updatedb.service which calls the /usr/libexec/mlocate-run-updatedb script. If we look at its contents:

$ sudo cat /usr/libexec/mlocate-run-updatedb
#!/usr/bin/sh

nodevs=$(< /proc/filesystems awk '$1 == "nodev" && $2 != "rootfs" && $2 != "zfs" { print $2 }')
/usr/bin/updatedb -f "$nodevs"

when it calls updatedb, it adds more filesystems to the command using the -f option:

$ nodevs=$(< /proc/filesystems awk '$1 == "nodev" && $2 != "rootfs" && $2 != "zfs" { print $2 }')

$ echo $nodevs
sysfs tmpfs bdev proc cgroup cgroup2 cpuset devtmpfs configfs debugfs tracefs securityfs sockfs bpf pipefs ramfs hugetlbfs devpts autofs mqueue selinuxfs pstore fuse fusectl rpc_pipefs overlay

So, if updating updatedb.conf isn’t working, perhaps its worth checking if this invocation of updatedb is adding nfs to the prune list? Running the above commands should tell you. (I don’t have an nfs mount, so I can’t test it myself).

Edit: just saw @lcts’s reply now. Luckily we’re suggesting similar solutions :slight_smile:

4

Hi lcts,

Firstly, nfs mount is on a custom directory.

Changing the /usr/libexec/mlocate-run-updatedb script was what I did on F30 (and maybe sooner) but I did a clean install on F32 and see the issue coming back.
Changing the nodevs line in the script to
nodevs=$(< /proc/filesystems awk '$1 == "nodev" && $2 != "rootfs" && $2 != "zfs" && $2 !~ "nfs" { print $2 }')
solves it for me but it would be more convenient to have one central config file.

$ grep nfs /proc/filesystems 
nodev   nfs
nodev   nfs4

So if I unprune nfs in /etc/updatedb.conf by removing nfs from the PRUNEFS line it will be put back by /usr/libexec/mlocate-run-updatedb

$ echo $(< /proc/filesystems awk '$1 == "nodev" && $2 != "rootfs" && $2 != "zfs" { print $2 }')
sysfs tmpfs bdev proc cgroup cgroup2 cpuset devtmpfs configfs debugfs tracefs securityfs sockfs bpf pipefs ramfs hugetlbfs devpts autofs mqueue selinuxfs pstore fuse fusectl rpc_pipefs nfs nfs4

I did some tests changing the PRUNEPATHS line in the config file and am now convinced the config file is read and works mostly as expected.

Thanks for your answer.

5

Since your fix will be undone the next time the mlocate package is updated, you should definitely file a bug against mlocate to have this included. There’s already an exception for ZFS in the script, after all.

In the meantime, you can prevent mlocate from being updated by setting excludepkgs='mlocate' in the [main]-section of /etc/dnf/dnf.conf.

1 Like
6

Thanks FranciscoD,
just got my Certified badge. :slight_smile:

2 Likes
7

I thought I’d first ask here before filing a bug.

$ rpm -qi mlocate | grep URL
URL         : https://fedorahosted.org/mlocate/
Bug URL     : https://bugz.fedoraproject.org/mlocate

urls are broken, package needs some maintenance.

2 Likes
8

Yeah, those URLs are definitely out of date. bugzilla.redhat.com is generally the right place to report bugs in Fedora packages.

1 Like
9

https://bugz.fedoraproject.org/mlocate is OK. That’ll work. It directs to the Fedora packages application. If it doesn’t work, that’s because the packages app is in the middle of a re-write so has some issues :slightly_frowning_face:

More instructions here: How to file a bug :: Fedora Docs

(You could also mention the outdated upstream URL in the bug)

10

https://bugzilla.redhat.com/show_bug.cgi?id=1845275

Thanks for your help.

1 Like