Linux - SoftwareThis forum is for Software issues.
Having a problem installing a new program? Want to know which application is best for the job? Post your question in this forum.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
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.
Athlon XP 2400, Abit MB, 1G ram, Ubuntu 5.04
Never a problem until this started a few days ago
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.
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: Job `cron.monthly' terminated
Aug 26 18:21:18 localhost anacron: 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
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.
This is how I changed updatedb on my Slack system:
/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.
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.
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.
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.