Running Maintenance Scripts...

My shell scripting abilities are almost non-existent, and I’m wondering if this appears to be a safe, appropriate means to run the periodic UNIX maintenance scripts.

Since it returns no result (even when ‘do shell script’ is set to a variable), it’s hard to tell what’s going on.

One thing I noticed is that - after running it - I (reproducibly) get this from running ‘Repair Permissions’ in Disk Utility:

“Determining correct file permissions.
parent directory ./Users/Shared/SC Info does not exist
Permissions differ on ./private/var/log/secure.log, should be -rw------- , they are -rw-r-----
Owner and group corrected on ./private/var/log/secure.log
Permissions corrected on ./private/var/log/secure.log”

I’m on 10.4.11.


Peter B.

tell me to activate
display dialog "Run periodic maintenance scripts now...?" & return & return & "(Allow a minimum of 2-3 Minutes for scripts to complete.)" with title "Maintenance"

do shell script "periodic daily weekly monthly" with administrator privileges

tell me to activate
display dialog "Maintenance scripts complete." with title "Maintenance"

I have a 10.4.11 system here (upgraded from 10.3.9, so it may not be identical to a “fresh” or an "archive and install"ed 10.4.11). Based on my reading of the periodic and periodic.conf manpages and the scripts and configuration files involved (/usr/sbin/periodic itself is a shell script, /etc/periodic// are the daily/weekly/monthly scripts, and /etc/defaults/periodic.conf is a config file), it seems that no output is what you should expect for a successful run of your command. If you want it, all the actual output is appended to these log files: /var/log/daily.log, /var/log/weekly.log, and /var/log/monthly.log.

It should be safe to run these as often as you like, but I have personally never felt the need to force the execution of these periodic jobs. By default, launchd is configured to run these every once in a while. The manpage (launchd.plist) even says it will run them later if the computer is off or asleep during the normally scheduled run time (though this does not seem to be completely reliable on my system). If you run them too often you will abbreviate your “log horizon” because it will rotate the files each time but only for a limited number of rotations (7 or 4 depending on which file). So if the monthly job is run daily and has a limit of 4 rotations for the files it rotates, you will end up wtih 4 days worth of logs instead of 4 months.

The “Repair Permissions” message about SC Info is probably unimportant and unrelated to periodic usage. I have read that the /Uesrs/Shared/SC Info folder (which is usually hidden from Finder) is used to hold iTunes DRM authorizations (when someone authorizes downloads made under their iTunes account to play on your computer, something is stored in there). My guess is that you do not use iTunes or at least do not use it with iTunes Music Store derived music files. To make this error go away, you could try creating the folder, or locating whatever “receipts” (/Library/Receipts) might mention SC Info (you might try Pacifist if find/xargs/lsbom/less/grep scripting is unfamilar; I did not find any such receipt on my system.). Once you know what is expecting SC Info you could try uninstalling it (be sure the receipt is removed too, or the “Repair Permission” message will persist).

-- Create and hide "/Users/Shared/SC Info"
set |SC Info POSIX path| to "/Users/Shared/SC Info"
do shell script "mkdir " & quoted form of |SC Info POSIX path| & ";chmod 777 " & quoted form of |SC Info POSIX path|
tell application "System Events" to set visible of disk item |SC Info POSIX path| to false

The secure.log message comes up since after the /etc/periodic/weekly/500.weekly has rotated the secure.log file, it recreates it as root:admin with ˜640’ permission (˜640’ (octal) equals ˜rw-r-----‘, which (in terms of root:admin user-owner:group-owner) means root user gets read and write, admin group gets read, everyone else has no permission). On my system /Library/Receipts/BaseSystem.pkg specifies secure.log to be root:admin with ˜600’ permission (equals ˜rw-------', root user gets read and write, everyone else has no permission). In my opinion, this is not a serious problem. The script creates files that the admin group can read, but any user in the admin group is (as far as I can tell) a de jure administrator of the computer. There seems very little harm in letting them read the file when they could just as easily sudo and read it if it was root-only as BaseSystem specifies. You could attempt to fix this problem by hacking the 500.weekly script to leave secure.log with the expected permissions. I could tell you exactly what to do, but I really would not recommend bothering.

Summary: The SC Info message is likely related to your non-use of iTunes DRM and could probably be ˜fixed’ by creating the folder in question. The secure.log message is directly related to running periodic’s weekly job. You could hack the script to prevent the minor slackening in permissions or just ignore it (as a long time Unix admin, but a johnny-come-lately to Mac OS X (10.3 in 2004), I wholeheartedly agree with John Gruber’s take on “Repair Permissions”: Seriously, ˜Repair Permissions’ Is Voodoo).


Thanks much for the detailed reply…

If it wasn’t clear, I typically run the maintenance scripts ‘manually’, because my computer is (almost) always off or sleeping at the default auto-run times. But this leads to sort of a random pattern as to when (or if) I run them at all… I actually seldom bother except when I’m moved to perform other maintenance tasks.

On 10.4.3, I had more frequent (minor) disk corruption problems and was fairly often verifying the disk… and as a matter of course, repairing permissions while I was in Disk Utility… followed by the daily, weekly and monthly scripts via OnyX. 10.4.11 seems less prone to such problems and OnyX seems a bit like overkill simply to run the maintenance scripts.

So… I thought I’d put together something quicker and simpler and the script I posted was the result.

However, I may adopt (and or adapt) Nigel Garvey’s script here:

… that (with modification) checks the relevant logs for the last time the specific script was run… and runs only those recommended at that interval.

I was aware the secure.log was somehow affected, but sort of surprised the maintenance script would alter the permissions… again, thanks for the explanation.

To be honest, the only times I’ve found it either necessary or ‘desirable’ to repair permissions have been (as recommended by some) after installing some software packages, after ‘fiddling’ in folders where perhaps I ought not, and once when I cloned my drive to an external via Disk Utility… and (it appeared as though) permissions for the entire clone had to be repaired to get it to boot.

(By the way, you’re right… I’m not an iTunes user. My ‘life’ is mostly still on vinyl.)

Peter B.