updatedb locks system

mherring02 · 08-25-2005, 10:11 PM

Several times recently, I have found my computer almost paralyzed---running slowly that it is essentially unusable.
A quick check of system monitor shows that "updatedb" is running an consuming ~97% of CPU. Killing this process brings everything back to normal.
I am not familiar with setting up cron jobs---and have never toched anything in that area, but I gather that there may be something running automatically and getting stuck.

Any hints??

Athlon XP 2400, Abit MB, 1G ram, Ubuntu 5.04
Never a problem until this started a few days ago

archtoad6 · 08-26-2005, 01:51 PM

Killing updatedb is not a good idea unless you never want to take advantage of the speed & convenience of the locate command. Better to wait out the slowdown, it doesn't take that long:

Code:

# date;updatedb;date
Fri Aug 26 13:40:58 CDT 2005
Fri Aug 26 13:43:11 CDT 2005

That's 2 min 13 sec on a 750 Duron, 192 MB RAM, approx 15 GB being scanned (mounted & used).

Did you notice what time of day this happened?

Please post your /etc/crontab
Perhaps rescheduling the cron job is the answer.

jdogpc · 08-26-2005, 05:46 PM

Hi mherring02,
not all distros are configured to run updatedb on a cron schedule nowadays, but if is configured to run from there it should be configured to run weekly so go to /etc/cron.weekly and delete or updatedb file from there.
That should solve your problem. Don't forget that if you ever want to use "locate" to search for some files you need to run "updatedb" manually as root.

bigrigdriver · 08-26-2005, 08:09 PM

And, whatever you do, don't setup updatedb to run at boot. Unless you want enough time to suck down a few beers waiting for the system to boot and be usable.

mherring02 · 08-27-2005, 10:26 AM

Thanks for all the inputs...

In chasing this, I have found interesting evidence which I can not yet tie together:
Syslog shows that the system has gone into neverland repeatedly trying to access my external USB drive (/dev/sda)--the dates match when I was finding the system locked up. Here is a typical entry:
Aug 26 18:21:18 localhost anacron[24163]: Job `cron.monthly' terminated
Aug 26 18:21:18 localhost anacron[24163]: Normal exit (2 jobs run)
Aug 26 18:21:18 localhost kernel: Current sda: sense key No Sense
Aug 26 18:21:39 localhost last message repeated 15 times
Aug 26 18:22:39 localhost last message repeated 9 times
Aug 26 18:22:39 localhost kernel: FAT: Filesystem panic (dev sda1)
Aug 26 18:22:39 localhost kernel: invalid access to FAT (entry 0x21110b46)

<<followed by a bazillion more of the same>>

Note that it got in trouble AFTER anacron was done

checking mail messages:

for the period in question, there are daily messages indicating that updatedb was terminated---that presumably relates to my manual intervention every time I found the computer locked up.

Earlier (before the trouble), there are two interesting messages:
May 20: unable to locate /var/lib/slocate/slocate.db
Aug 10: segmentation fault usr/bin/updatedb

(the next mail message was the first of the series where the trouble started)

Just now, I ran updatedb manually and it completed in ~ 1.5 minutes with no ill effects.

I feel I am on the trail, but still not close the answer

camelrider · 08-28-2005, 09:38 AM

Two suggestions:

1) You can edit the updatedb line in your cron files to exclude your usb drive if that is the only thing causing a problem. (See man updatedb. I think the -e switch will help)

2) You can run the updatedb command with an elevated nice value. (see man nice) In the days of i386 boxen with only a few MB of RAM nice was a pretty popular utility. It prevents a single process from hogging resources.

Hope this helps.

sundialsvcs · 08-28-2005, 11:34 AM

I suspect that the USB drive may well be the root cause of the problem.

As suggested, I routinely use nice updatedb, so that the process runs at lower priority. Of course, it's an "I/O bound" process anyway, so priority doesn't matter so much.

And I schedule the daily run for 2:00 AM local time.

mlangdn · 08-28-2005, 11:59 AM

This is how I changed updatedb on my Slack system:

#!/bin/sh
/usr/bin/updatedb -f "nfs,smbfs,ncpfs,proc,devpts" -e "/tmp,/var/tmp,usr/tmp,/afs,/net,/mnt/win98,/mnt/winxp,/mnt/Suse,/mnt/hda7"
This script is located at /etc/cron.daily - it may be different for other distros.

-f excludes the specified filesystem types
-e excludes the specified directories.

These are the places I don't want or need to be indexed. Change to suit your system.

mherring02 · 08-28-2005, 02:06 PM

Thanks to everyone---now I understand cron and related things.

curiously, since I was grubbing around looking for clues, things have been OK. Reminds me of when I was 10--and could fix lawnmowers by taking them apart and reassembling---at the time I never knew WHY....

I claim that computers are not deterministic--for the simple reason that their "mother" never knows EXACTLY what is inside.

jdogpc · 08-28-2005, 04:54 PM

Hi mherring02, by your post I think you should check your external hdd as it appears to have some problems.
Run a fsck as root to check it out, with look it's just logical problems.

umount /dev/sda1
fsck.vfat -rtv /dev/sda1

-r - interactive
-t - test for bas clusters
-v - verbose

this will take a while.
in case you see some errors identical to the ones you mentioned earlier and you think the hdd is ok test it on another machine or with another operating system, as this could also be a problem of your kernel modules either scsi emulation which I don't think so or usb driver.

Good Luck

JDOGPC