我注意到cron.daily
那次运行updatedb.locate
要花很长时间才能完成(如果能完成的话)。我中断了上次运行,发现它占用了超过 16 小时的 CPU 时间。
经过一番调查,我发现 find 正在索引巨大的 nfs 挂载文件系统。尽管 nfs 被列为应跳过的文件系统之一,但它本身PRUNEFS
/etc/updatedb.conf
也是如此:PRUNEFS
/etc/cron.daily/locate
illia@illia-vm1:~$ grep PRUNEFS /etc/cron.daily/locate
PRUNEFS="NFS nfs nfs4 afs binfmt_misc proc smbfs autofs iso9660 ncpfs coda devpts ftpfs devfs mfs shfs sysfs cifs lustre_lite tmpfs usbfs udf ocfs2"
export FINDOPTIONS PRUNEFS PRUNEPATHS NETPATHS LOCALUSER
事实证明,如果文件系统在其他地方绑定挂载,find 将看不到它的实际类型,而是将其视为类型为“none”:
illia@illia-vm1:~$ mount | grep /shared
/shared on /var/lib/schroot/mount/<cut>/shared type none (ro,bind)
<cut>:/shared on /shared type nfs (ro,intr,soft,tcp,bg,nordirplus,addr=<cut>)
illia@illia-vm1:~$ find /shared -printf "%F %p\n"
none /shared
none /shared/<cut>
none /shared/<cut>
none /shared/<cut>
none /shared/<cut>
...
我找到了一个相当古老的 Debian 错误来讨论这个问题:
http://savannah.gnu.org/bugs/index.php?func=detailitem&item_id=14921 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=329385
我可以自己修复此问题,方法是将“none”添加到PRUNEFS
中/etc/updatedb.conf
,然后创建/etc/updatedb.findutils.cron.local
也将“none”添加到的版本PRUNEFS
。
我想知道此时正确的做法是什么?Debian 错误似乎只是表明问题存在,find
最好修复。我想既然有一个解决方法,这个错误实际上并没有给任何人带来太多困扰。我不知道 Debian 发行版中是否有解决方法,但它似乎没有出现在 Lubuntu(我猜还有 Ubuntu)中。我应该怎么做才能将该解决方法应用于 Ubuntu 系统?