The macosxhints Forums - Updating locate.updatedb daily instead of weekly

The macosxhints Forums (http://hintsforums.macworld.com/index.php)

- UNIX - Newcomers (http://hintsforums.macworld.com/forumdisplay.php?f=15)

- - Updating locate.updatedb daily instead of weekly (http://hintsforums.macworld.com/showthread.php?t=4678)

Can't /usr/libexec/locate.updatedb remain -x all the time, only to be +x at the beginning of the daily.local, and then turned back to -x at the end of daily.local? That way it is always -x except when daily.local is running. That would trip the if statement in the weekly script to bypass that part without any modification.

Is there anything else using /usr/libexec/locate.updatedb other than just weekly and our new daily.local?

vicki, there you go. well done **

nothing else that i know of runs the updatedb, and if it does, then it'll obvious what the problem is. but the solution will be alluding unless we know that we've done this, right? best to leave a lot of notes and documentation about what we're doing here, like the url to this thread :D

but, this also works well on the un-exec'd script

% sudo csh /usr/libexec/locate.updatedb

Couldn't you check what day it is in the daily.local script? something like

Code:

if [ `date +%w` -ne 0 ] then run the update_locatedb

basically, check if it's Sunday(I think the weekly runs Sunday) if it ain't run the update_locatedb for the daily.local. This way you aren't modifying files perms and such. Just a thought. Oh, and please fix my code if it's wrong, I didn't really test it or anything.

Ok, I was backwards with the nice stuff! 'nice -5' will make it chew more CPU and be not nice (actually the csh nice works the same way if you read the man page, don't know what that BUGS section is on about nkuvu, maybe it is just an artifact from the olden days..). Hmm, maybe I was up late at one time and found the command was grinding things to a halt.... anyway....

As for the '2>&1', probably a (nother? 8-) typo on my part.

The reason that is there is because when the script runs as 'nobody' it tries to read lots of directories that it does not have permission to read, hence there are a lot of messages saying 'Permission denied' that go out to stderr.

As an aside, in UNIX all processes get started with 3 input/output 'files'. There is stdin (0) which is the input to the program. There is stdout (1) which is the normal output of the program. And there is stderr (2) which is the error output of the program. stderr is there as a way to get error messages out even though you output is redirected (or piped) to another program. Try this:

Code:

% ls kkkk | grep fishheads

ls: kkkk: No such file or directory

% sh

strider% ls kkkk 2>&1 | grep fishheads

strider% ls kkkk 2>&1 | grep kkkk     

ls: kkkk: No such file or directory

Now, the file kkkk does not exist and in:
Case 1) The error message about the file kkkk not existing gets sent to stderr and not piped through to the grep command which is why we see it.
Case 2) (go into 'sh' as this does not work in csh's) The stderr and stdout are piped to the grep cammand which doesn't matches fishheads hence no output.
Case 3) again stderr is piped with stdout but the grep catches the error text this time.

So, there will be lots of 'Permmision denied' messages coming out of the update script when it is run by 'nobody'. Now you could just redirect stderr to /dev/null, but then you might miss a 'real' error of some other type. So the '2>&1' says to send the stderr (2) out to the same place as stdout(1) and then we will pipe the whole lot through sed and delete all the permission denied messages. Any other errors will still show up and end up in the email that these scripts send to root (which apple's default setup ends up sending to /dev/null anyway, but that is another story!)

Whew. Now, since I am no longer running this as 'nobody', I am running as 'root' so I will never see those 'Permission denied' errors because I can see everything on my box. So in effect it does not make any difference to me.

As for Merv's catch on the fact that the weekly will produce different output than the daily and the fixes for that etc. that is right on. I guess that is why I just went ahead and hacked the weekly script. 8-)

I think I have just thought of a good project for myself. Some type of database that lets you list a number of files (and maybe stores the originals and check sums of the new versions) and it lets you type in some text describing why you hacked the files. Then after any systems upgrades you could run a check for anything that it 'reset' back to normal and investigate if you still need your hack. Come to think of it I suppose I could use CVS for this.... hmmmmm.

Doug, thank you for explaining it to me! That helps quite a bit. :)

I've decided it's best to put a warning on my sig line so I don't confuse others since I'm more wrong than right half the time!