Percebi que cron.daily que executa updatedb.locate estava falando muito tempo para ser concluído (se alguma vez for concluído). Eu interrompi a última execução com a descoberta de mais de 16 horas de tempo de CPU.
Após investigar um pouco, descobri que find estava indexando o enorme sistema de arquivos nfs montado. Apesar do fato de o nfs estar listado como um dos sistemas de arquivos, ele deve ser ignorado em PRUNEFS /etc/updatedb.conf , bem como em PRUNEFS in /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
Descobriu-se que, se um sistema de arquivos é vinculado em outro lugar, o find não verá seu tipo real, mas, em vez disso, ele tratará do tipo '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>
...
Consegui encontrar um bug do Debian antigo discutindo esse problema:
link
link
Eu posso consertar isso sozinho adicionando "nenhum" a PRUNEFS em /etc/updatedb.conf e criando /etc/updatedb.findutils.cron.local que também adicionaria "nenhum" a PRUNEFS .
Eu queria saber qual seria a ação certa aqui?
Parece que o bug do Debian apenas declara que o problema está lá e find better seja corrigido.
Eu acho que como há uma solução alternativa, o bug não estava realmente incomodando ninguém demais.
Eu não sei se a solução alternativa está na distribuição Debian, mas parece estar ausente do Lubuntu (e do Ubuntu eu acho).
O que devo fazer para que essa solução alternativa seja aplicada aos sistemas Ubuntu?