Submit Hint Search The Forums LinksStatsPollsHeadlinesRSS
14,000 hints and counting!

A shell script to kill the updatedb process UNIX
The locate command is a beautiful thing. It's ugly but critically-useful cousin is updatedb, which periodically runs a series of commands (most noticably, the useful and resource-intensive find) to find all files (with some configurable exceptions) on the system and put them in a database. So when you want to quickly find a file on your system, you use locate, which queries the database and tells you where the file was when the database was last updated. OK, enough background.

The only problem with the locate package (of which updatedb is a part) is the updatedb process itself. It thrashes the disk and uses a lot of CPU. It's set up by default to run four times a day, at noon, midnight, six in the morning and six in the evening. Sometimes these times are convenient and sometimes they're not. If I'm using my computer at all during these times, it's easy to notice when the process starts and I can't stand it.

I finally wrote a reasonably-simple script called killupdate, which I run with sudo. And here it is (the PIDS line is shown on two rows; remove the line break and insert a space instead):


#!/bin/sh
PIDS=`ps ax | grep 'updatedb\|find' | grep -v grep | sort | awk
  '{print $1}' | perl -ne 'chomp;print "$_ "'`
if [ "$PIDS" ]
  then kill $PIDS
fi
Probably not the best code in the world. Actually it's definitely not ... too many processes piped together. Yes, it's a shell script that calls perl -- I do that way too often, but it's so useful and I'm more familiar with perl ... but some programs make more sense as shell scripts, so I end up using shell and perl together like this a lot... sue me :)

Also notice that we're grepping the process list for all processes named "updatedb" or "find." This is potentially dangerous, especially on a multiuser system, because this could kill other people's find processes. I'm the only user on my machine, so this isn't an issue for me. I'm only sharing this code as-is because I find it useful.

Of course, if you're always at your computer when updatedb wants to run, it's best to let it run from time to time so your database is current. But I figure mine runs at least once every 24 hours, and that's enough for me. But the four-times-per-day default setup is also good, because I never know what time I'm going to be using the computer.

Better code is encouraged. Please post it in your comments.

[robg adds: The only part of this hint I'm unsure of is the four times a day updating of the database. On my machine, the "weekly" task runs updatedb on Saturdays at 4:30am. In looking at the current database (ls -al /var/db/loc*), it was last updated at 4:37am on Saturday the 20th. I've been on my machine since 4:00am today, and there was no 6:00am update ... anyone have any thoughts on the disparity?]

    •    
  • Currently 1.50 / 5
  • 1
  • 2
  • 3
  • 4
  • 5
  (2 votes cast)
 
[15,550 views]  

A shell script to kill the updatedb process | 15 comments | Create New Account
Click here to return to the 'A shell script to kill the updatedb process' hint
The following comments are owned by whoever posted them. This site is not responsible for what they say.
A shell script to kill the updatedb process
Authored by: foobar104 on Sep 22, '03 11:38:47AM

killall updatedb



[ Reply to This | # ]
A shell script to kill the updatedb process
Authored by: olwylee on Sep 22, '03 11:41:27AM

I get the same result as Rob, locate.database is only updated once a week. Mine was last done, (Sep 20 04:32 /var/db/locate.database). My understanding is that updatedb only runs once a week unless you use an app. like OnyX to force the update at other times.

To my knowledge there is no script set up to run 4 times a day by default and if this is happening on your system you might want to investigate as to why and how it got set up that way.



[ Reply to This | # ]
A shell script to kill the updatedb process
Authored by: Scottie on Sep 22, '03 12:58:44PM

My Powerbook hasn't update the locate.database since July 2002. It's never on at 4:30am.

How can you reschedule the scripts for a time when it would be on?



[ Reply to This | # ]
A shell script to kill the updatedb process
Authored by: babertocci on Sep 22, '03 01:41:32PM
The info for when system level periodic scripts will run is contained in /etc/crontab.

30 3 * * 6 root periodic weekly

This is a possible entry for weekly. This means that the weekly script is set to run at 3:30 AM on Saturday. The columns go Minute - Hour - Day of Month - Month - Day of Week - User running the cron job - Command. Any field contain the * is a wildcard. Most of the jobs are set by default to run at the wee hours of the morning. To change them, edit the second column to whatever hour you would rather have them run. You can change weekday and minute as well if you are so inclined.

[ Reply to This | # ]
A shell script to kill the updatedb process
Authored by: langer on Sep 22, '03 10:53:13PM
My Powerbook hasn't update the locate.database since July 2002. It's never on at 4:30am.

How can you reschedule the scripts for a time when it would be on?

Get anacron from fink. Anacron is more suitable than cron for computers that are off much of the time. Instead of running jobs at specific times (such as 4:30 AM on Saturday) it runs them if they haven't been run within a specified interval. For example, you could tell anacron to run updatedb once a week. It can be configured to run the scripts that cron usually runs.

I don't know why anacron isn't set up by default. It can actually be quite important. Until I installed it, my system log files were enormous -- they were never rotated or compressed because cron wanted to do that at 7 AM.

-- Steve

[ Reply to This | # ]

A shell script to kill the updatedb process
Authored by: foobar104 on Sep 23, '03 12:23:53AM

A much better suggestion is to get anacron from <a href="http://www.apple.com/downloads/macosx/unix_open_source/anacron.html">here</a>. That way you don't have to clutter your machine with Fink.



[ Reply to This | # ]
A shell script to kill the updatedb process
Authored by: DC Watts on Sep 24, '03 08:43:32PM


"hasn't updated the locate.database since July 2002."

Scottie, from the KISS standpoint, do you really use locate all that much? 'Cause if you don't, you can easily disable locdb updating and then scream through the weekly crontask in practically no time. Under such circumstances, you might just run the weekly by hand when you need to and avoid editing crontabs. Just depends on how you use your Mac, I guess. Sorry if I've misunderstood.

[ Reply to This | # ]
This "hint" is ludicrous
Authored by: gatorparrots on Sep 22, '03 11:49:54AM
I would caution others against following this hint's advice.

Firstly, the author gives inaccurate information: the locate database is updated (as Rob G. thought) once per week via the weekly periodic script. By default, it is scheduled to run at 4:30 a.m. on Saturday. Therefore, it should not interfere with one's work or be very noticeable to a user.

Secondly, it's very inconsiderate and dangerous to go around indiscriminately nuking system-level process in the midst of operation. If anything, one could pause the task (with a -STOP command and resume it at a more convenient time.

Thirdly, the author shows bad scripting style by invoking perl within a Bourne shell script. The script should be written entirely within perl or else the following Bourne one-liner should suffice:
sudo kill `ps axww | awk '/updatedb/ {print $1}'` > /dev/null 2>&1

[ Reply to This | # ]

This "hint" is ludicrous
Authored by: dajwhite on Sep 23, '03 02:33:49PM

Pardon my ignorance, but why is it bad form to call perl from within a shell script? I've never heard of this being discouraged before.

Just curious...



[ Reply to This | # ]
This "hint" is ludicrous
Authored by: babbage on Sep 23, '03 02:59:55PM

Because Perl is *huge*. It's like writing a shell script to manipulate the data in a file, and using AppleScript (osascript) to pull in Microsoft Excel to do the work halfway through.

Excel can be a very useful tool, but there's so much overhead in calling it that for the most part you're better off by [a] going all out & using the heavyweight tool for everything you're trying to do (i.e. do it all in Perl, or Excel), or by [b] finding a way to solve the whole problem with lightweight tools.

By way of another analogy, loading Perl is like taking an airplane ticket somewhere. Sometimes, you want to go somewhere far, so traveling by air is the way to go. In other cases, the distance is short and there's no reason to get in a plane. Mixing Perl & shell code is often like travelling for many hundreds of miles by car, only to get in a plane for the last hundred.

There may be a good reason to do this, but usually it would be more efficient to just take the plane [Perl] the whole way, or find a route that doesn't involve pulling in such an expensive component for such a small portion of the task.

Make sense?


---
--
DO NOT LEAVE IT IS NOT REAL



[ Reply to This | # ]
This "hint" is ludicrous
Authored by: dajwhite on Sep 24, '03 11:19:24AM

Yep. It's always interesting to learn new coding viewpoints. I'm just glad to hear that your objection wasn't based on a technical problem since I've seen it done before and didn't want something biting us at a later date.



[ Reply to This | # ]
This "hint" is ludicrous
Authored by: readparse on Sep 25, '03 12:08:40PM

Thanks for the constructive criticism (well, at least inflammatory criticism). I'm the author of the hint, and you might have noticed my disclaimers about how there was probably a better way to do this. I think I specifically mentioned that calling perl from a shell pipeline wasn't the greatest way to go about it. I think I also mentioned the danger of killing "find" processes on a multi-user machine. I disclaimed and disclaimed some more.

I think I also asked for improvements. The first comment I saw in response was exactly that... "killall updatedb", which made me smile because I figured it probably worked and I was again guilty of overkill and embarassment. However, it happens to be 12:03, so updatedb is running right this second, and I just tried "sudo killall updatedb" and it didn't work. This makes me think that perhaps I had tried that approach earlier and it was one of many that did not work.

I also tried the renice approach, which was also suggested. I tried all of these things long before I finally wrote this script, which does exactly what I need. Yes, Perl is huge, and yet, this is not what I would call a "best practice". But this is something that just takes a moment to run, and it does exactly what I need. After having used it for many weeks with great success, I decided to share it with other users, that they might have similar success. Responses like yours are what keep people from sharing their ideas. It's not "ludicrous". It's "improvable".

Thanks anyway,
ReadParse



[ Reply to This | # ]
A shell script to kill the updatedb process
Authored by: jpbjpbjpbjpb on Sep 22, '03 02:17:06PM

rather than interrupt the updatedb process, you might want to consider editing the system crontab to include "nice -20" on each of the maintenance tasks.



[ Reply to This | # ]
A shell script to kill the updatedb process
Authored by: Bobson on Sep 22, '03 03:25:41PM

Don't you mean nice +20? Lowest priority?



[ Reply to This | # ]
XJanitor might fit better than anacron
Authored by: elmimmo on Sep 23, '03 03:01:32AM

Fink might sound very bohemian, but installing all that ports packaging system just to get anacron installed I think is rather a burden.

XJanitor, as pointed out in this other MacOSXHints' hint is quite a better option for those of us not really interested in tinkering with many Unix programs. It is not on-click install, but is still rather easy if you read the doc from start to end and download a cron helper such as Cronnix.

[ Reply to This | # ]