just noticed in /etc/updatedb.conf in F27, the snippet:
PRUNEPATHS = "... /udev ..."
not sure if /udev ever existed in fedora, but i think it's safe to say, it's not there now and probably won't be any time in the near future. and even though it doesn't *hurt* to have extraneous directory names in that list, is there any compelling reason to keep it there?
rday
On 03/06/18 04:51, Robert P. J. Day wrote:
just noticed in /etc/updatedb.conf in F27, the snippet:
PRUNEPATHS = "... /udev ..."
not sure if /udev ever existed in fedora, but i think it's safe to say, it's not there now and probably won't be any time in the near future. and even though it doesn't *hurt* to have extraneous directory names in that list, is there any compelling reason to keep it there?
You probably don't have /net, /var/spool/squid on your system. But you may know of a package or process that would create them. So, removing them may cause an issue for you should you make changes to your system at some point. The same could possibly be said about /udev.
Making changes for the sake of making changes is rarely a good idea.
On Tue, 6 Mar 2018, Ed Greshko wrote:
On 03/06/18 04:51, Robert P. J. Day wrote:
just noticed in /etc/updatedb.conf in F27, the snippet:
PRUNEPATHS = "... /udev ..."
not sure if /udev ever existed in fedora, but i think it's safe to say, it's not there now and probably won't be any time in the near future. and even though it doesn't *hurt* to have extraneous directory names in that list, is there any compelling reason to keep it there?
You probably don't have /net, /var/spool/squid on your system. But you may know of a package or process that would create them. So, removing them may cause an issue for you should you make changes to your system at some point. The same could possibly be said about /udev.
it's only the mlocate database, i doubt incorrect output is going to cause any system issues. :-)
Making changes for the sake of making changes is rarely a good idea.
i realize change for the sake of change is not necessarily a good plan, but i don't recall udev *ever* creating a top-level /udev directory (maybe i just missed it). i'm also sure that such a directory would be unsupported by the current incarnation of udev.
i understand there's no actual harm in having extraneous directories in that list, but various linux vendors tweak packages all the time for their particular distros. for instance, "man updatedb.conf" on my fedora 27 system claims:
PRUNEPATHS A whitespace-separated list of path names of directories which should not be scanned by updatedb(8). Each path name must be exactly in the form in which the directory would be reported by locate(1).
By default, no paths are skipped. <------------ there
and yet, my current /etc/updatedb.conf (which i have never modified to the best of my knowledge), contains:
PRUNEPATHS = "/afs /media /mnt /net /sfs /tmp /udev /var/cache/ccache /var/lib/yum/yumdb /var/lib/dnf/yumdb /var/spool/cups /var/spool/squid /var/tmp /var/lib/ceph"
so it would seem that red hat is already customizing that file in contrast to what the man page says. just pointing out that red hat is already making some changes here.
rday
On 03/06/18 18:29, Robert P. J. Day wrote:
On Tue, 6 Mar 2018, Ed Greshko wrote:
On 03/06/18 04:51, Robert P. J. Day wrote:
just noticed in /etc/updatedb.conf in F27, the snippet:
PRUNEPATHS = "... /udev ..."
not sure if /udev ever existed in fedora, but i think it's safe to say, it's not there now and probably won't be any time in the near future. and even though it doesn't *hurt* to have extraneous directory names in that list, is there any compelling reason to keep it there?
You probably don't have /net, /var/spool/squid on your system. But you may know of a package or process that would create them. So, removing them may cause an issue for you should you make changes to your system at some point. The same could possibly be said about /udev.
it's only the mlocate database, i doubt incorrect output is going to cause any system issues. :-)
Not saying any "incorrect" output would result or there would be any "system issues". But let's say you remove it from the prune list and a device gets mounted on that point that contains a large file system with many small files. Then you may be scratching your head wondering why your system is suddenly busy at times.
Making changes for the sake of making changes is rarely a good idea.
i realize change for the sake of change is not necessarily a good plan, but i don't recall udev *ever* creating a top-level /udev directory (maybe i just missed it). i'm also sure that such a directory would be unsupported by the current incarnation of udev.
i understand there's no actual harm in having extraneous directories in that list, but various linux vendors tweak packages all the time for their particular distros. for instance, "man updatedb.conf" on my fedora 27 system claims:
PRUNEPATHS A whitespace-separated list of path names of directories which should not be scanned by updatedb(8). Each path name must be exactly in the form in which the directory would be reported by locate(1).
By default, no paths are skipped. <------------ thereand yet, my current /etc/updatedb.conf (which i have never modified to the best of my knowledge), contains:
PRUNEPATHS = "/afs /media /mnt /net /sfs /tmp /udev /var/cache/ccache /var/lib/yum/yumdb /var/lib/dnf/yumdb /var/spool/cups /var/spool/squid /var/tmp /var/lib/ceph"
so it would seem that red hat is already customizing that file in contrast to what the man page says. just pointing out that red hat is already making some changes here.
There is no ambiguity in the man page. What the man page is saying is that in the absence of a PRUNEPATHS being specified no paths are skipped. The same goes for PRUNEFS. Without that specified all fs types will be searched. It is then up to the packager, or distro, to decide what makes sense for them and to define things accordingly.
The same thing goes for all config files, actually. You'll read the man page and it defines a given feature and what the default setting it. And, you *may* then look at the config file and find that the default value/setting has been changed. Those in charge package or distro have decided what is "best".
You want to change it? Go ahead. I make changes all the time to the "distro default settings". Like sshd, I don't allow passwords for authentication. Only keys.
-
Ed Greshko -
Robert P. J. Day