Hullo there,
There's a script in /etc/cron.daily (on debian-etch server) called 'find', which is starting at around 8.30 am, using 100% cpu power, then kind of sticking there for hours (I just had to manually kill the processes it seems to start, like locate and updatedb and sort). Below is the script, and updatedb.conf.
Has anyone any idea why this should be unable to run properly, and would it be a Bad Awful thing to just have it not run?
Thanks,
Jenny
jenny@xios:~$ sudo more /etc/cron.daily/find #! /bin/sh # # cron script to update the `locatedb' database. # # Written by Ian A. Murdock imurdock@debian.org and # Kevin Dalley kevin@aimnet.com
LOCALUSER="nobody" export LOCALUSER if [ -f /etc/updatedb.conf ]; then . /etc/updatedb.conf fi
if getent passwd $LOCALUSER > /dev/null ; then cd / && nice -n ${NICE:-10} updatedb 2>/dev/null else echo "User $LOCALUSER does not exist." exit 1 fi jenny@xios:~$ sudo more /etc/updatedb.conf # This file sets environment variables which are used by updatedb
# Global options for invocations of find(1) FINDOPTIONS='-ignore_readdir_race' export FINDOPTIONS # filesystems which are pruned from updatedb database 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" export PRUNEFS # paths which are pruned from updatedb database PRUNEPATHS="/tmp /usr/tmp /var/tmp /afs /amd /alex /var/spool /sfs /media" export PRUNEPATHS # netpaths which are added NETPATHS="" export NETPATHS # run find as this user LOCALUSER="nobody" export LOCALUSER # cron.daily/find: run at this priority -- higher number means lower priority # (this is relative to the default which cron sets, which is usually +5) NICE=10 export NICE
On Wed, Sep 12, 2007 at 10:36:55AM +0100, Jenny Hopkins wrote:
Hullo there,
There's a script in /etc/cron.daily (on debian-etch server) called 'find', which is starting at around 8.30 am, using 100% cpu power, then kind of sticking there for hours (I just had to manually kill the processes it seems to start, like locate and updatedb and sort). Below is the script, and updatedb.conf.
Has anyone any idea why this should be unable to run properly, and would it be a Bad Awful thing to just have it not run?
Network mounted filesystems? Large backup drive attached?
Add anything that might take "a long time" to run a find over to the PRUNEPATHS in updatedb.conf... even if they should be ignored because of the PRUNEFS setting, remove any network mounts (using PRUNEPATHS too).
If you do disable it, all you'll lose is the "locate" utility, which shouldn't be too big a loss ;)
Hope that helps,
On 12/09/2007, Brett Parker iDunno@sommitrealweird.co.uk wrote:
On Wed, Sep 12, 2007 at 10:36:55AM +0100, Jenny Hopkins wrote:
Hullo there,
There's a script in /etc/cron.daily (on debian-etch server) called 'find', which is starting at around 8.30 am, using 100% cpu power, then kind of sticking there for hours (I just had to manually kill the processes it seems to start, like locate and updatedb and sort). Below is the script, and updatedb.conf.
Has anyone any idea why this should be unable to run properly, and would it be a Bad Awful thing to just have it not run?
Network mounted filesystems? Large backup drive attached?
Oh indeed - it's the backup server!
Add anything that might take "a long time" to run a find over to the PRUNEPATHS in updatedb.conf... even if they should be ignored because of the PRUNEFS setting, remove any network mounts (using PRUNEPATHS too).
If you do disable it, all you'll lose is the "locate" utility, which shouldn't be too big a loss ;)
I can simply add /home/dirvish and about 250G of backup will be missed out.
Hope that helps,
Yes, thanks Brett - brilliant!
Jenny