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

Repair permissions to resolve slow system issues System
Last night my big OS X partition became very slow to work. Today, I went to the smaller, barer one to use Disk Utility. Bad choice, it took 12 bounces to launch. Dead slow to run "Repair Disk Permissions." So I booted from the "Jaguar" Install Disk, and it worked about twice as fast and fixed the "Disk Permissions" on both partitions. Now it works much better.

Nearly all of the problems were on both partitions, and v10.2.6 was the last thing to touch them. Apple's updates do not seem to be the cleanest or friendliest, if you check the partition after installing. I'll now use Disk Utility and Drive 10 after each update.

[robg adds: As a general rule, running Repair Permissions once a month or so is a good idea. I occasionally lapse at this, and when I remember to do so, there are always a few glitches to be fixed. I won't necessarily blame the Apple updates, as I install and test a ton of software. Keep in mind that if you have special permissions established, such as for sendmail, they'll get wiped out by the Repair Permissions utility.

Also, if you're looking at things to help keep your machine in tip-top shape, run Console occasionally. Keep an eye on the console log (the one that opens by default), as well as the system log (in the Open Log dialog, enter /var/logs into the "Go To" line, then select system.log in that directory). These two logs can give you a very good glimpse at the overall health of your machine.]
    •    
  • Currently 3.00 / 5
  You rated: 5 / 5 (2 votes cast)
 
[23,065 views]  

Repair permissions to resolve slow system issues | 15 comments | Create New Account
Click here to return to the 'Repair permissions to resolve slow system issues' hint
The following comments are owned by whoever posted them. This site is not responsible for what they say.
Repair permissions to resolve slow system issues
Authored by: sumnchai on May 30, '03 12:33:01PM
Slight correction: it should be /var/log/system.log not /var/logs/system.log

[ Reply to This | # ]
Repair permissions to resolve slow system issues
Authored by: Niru on May 30, '03 02:05:21PM

For the longest time, I could not understand why permissions had anything at all to do with performance.

Either a file can be opened or it could not.

However - wonky permissions can interfere with the prebinding process. Apps can still launch non-prebound. (or, sometimes, apparently, they'll crash).
But without that prebinding, or with an incorrect prebinding, it'll at least be slower.



[ Reply to This | # ]
Repair permissions to resolve slow system issues
Authored by: acroyear on May 31, '03 12:23:49PM

Right, and running non-prebound in my experience simply means about 5 minutes of sloth, while the system tracks down the libraries in real time.

I have a hard time believing that repairing permissions does all the miraculous things people are claiming it does. I am starting to wonder if this will be Mac OS X's equivalent of the "rebuild the desktop" supposed panacea. As you say, either a file will open or it won't. I've yet to see a BareFeats or XLR8YourMac site do even a sorta scientific test.

Even the original article shows us that the writer rebooted his Mac, which has actually been the main thing that has sped up slow systems I've been on (since memory gets freed up, there's less paging, and the hard drive gets rid of multiple VM swap files).

Now, all that said, can anyone tell me why whenever I check Ownership & Permissions on a file in the Finder, I get apparently varying gibberish/non-Roman characters followed by (Me) [okay, the "Me" I get, but why the rest of it? It's an English only system]?

--Acroyear



[ Reply to This | # ]
Repair permissions to resolve slow system issues
Authored by: tciuro on May 30, '03 02:37:36PM

Alternatively, you can launch Console.app in /Applications/Utilities. When you do, the system log will be loaded for you automatically.



[ Reply to This | # ]
Repair permissions to resolve slow system issues
Authored by: ratpH1nk on May 30, '03 04:28:14PM

actually opening the console.app opens the console.log. This file is different than the system.log. You can open the system.log from the console File -->Open Log



[ Reply to This | # ]
Repair permissions to resolve slow system issues
Authored by: guybrush on May 30, '03 03:28:58PM

Uhm must be me, but i dont understand it, why do the file permissions affect the performance?



[ Reply to This | # ]
Repair permissions to resolve slow system issues
Authored by: Anonymous on Jun 02, '03 10:02:00AM
It's not just you. Disk permissions have nothing in the world to do with system speed. Either access to a file, directory, device, pipe, etc. is allowed or denied. Having non-default permissions will not slow down file access - it will only allow or deny it. Booting from the install disk probably helped this guy out by running fsck, replaying disk journals, or cleaning up the volumes some other way.

I see absolutely no reason to (a) screw around with your disk permissions and (b) run the permission reset thingy regularly. If you don't know what the permissions of a file should be and why, you shouldn't be messing with the permissions or running the permission reset doodad. If installing certain software is the cause of permission changes, reconsider installing the software. Then again, if you fully understand how disk permissions work, application installers that change permissions shouldn't be a problem for you.

The original hint is incorrect and very misleading to the UNIX newbies here.

---
--
Gypsy

[ Reply to This | # ]

Repair permissions to resolve slow system issues
Authored by: ratpH1nk on May 30, '03 04:25:30PM

There is no reason you could not run diskutil as a cron job

use diskutil list to get the identifer for your HD

then run diskutil repairPermissions <identifer>

once per month sound great, if you do not mind apple's default permissions set.



[ Reply to This | # ]
Repair permissions to resolve slow system issues
Authored by: DanFrakes on May 31, '03 02:26:00AM

Repair Permissions via the diskutil command requires an admin password to run (i.e., it has to be run as root). You'd need to set up a shell script or AppleScript that includes a password. I've set up an AppleScript that runs Repair Permissions every Saturday morning and outputs the log to my Desktop.

---
------------------------------------------
Mac OS X Power Tools:
http://www.macosxpowertools.com/



[ Reply to This | # ]
Repair permissions to resolve slow system issues
Authored by: Alrescha on May 31, '03 10:23:53AM

"You'd need to set up a shell script or AppleScript that includes a password."

That isn't always a good idea. If you have set a root password, just set up the crontab entry as root.

A.



[ Reply to This | # ]
Repair permissions to resolve slow system issues
Authored by: DanFrakes on Jun 01, '03 03:29:55PM

If you keep the script in your own user directory, it's not a problem (Anyone who can get into your user directory to access the script already has enough access that getting your password isn't going to matter much ;))

I agree that keeping it elsewhere is a security risk.


Porkchop, I realize that diskutil is a command-line program, and that AppleScript isn't "needed." But you can use AppleScript to run command-line programs, and running an AppleScript via cron is an easy way to set up a schedule like this without having to edit the root/system crontab (i.e. you can run it from a user-level crontab, which is preferred to editing the root/system crontab).

---
------------------------------------------
Mac OS X Power Tools:
http://www.macosxpowertools.com/



[ Reply to This | # ]
Root password needed?
Authored by: porkchop_d_clown on May 31, '03 02:24:47PM

Ummmm... cron jobs are already run as root, and diskutil is a command line version of the disk utilitiy. Applescript isn't needed.

The only real problem with cron is you have to leave your machine running 24 hours a day, which is why I use anacron instead.

---
Everyone loves a clown, but no one will lend him money!



[ Reply to This | # ]
Root password needed?
Authored by: Alrescha on May 31, '03 05:30:03PM

"Ummmm... cron jobs are already run as root.."

Unless Darwin/OS X acts differently than all other unixes that I have experienced, cron jobs run as the user who added them. This is not necessarily root.

A.



[ Reply to This | # ]
Root password needed?
Authored by: MacTed on May 31, '03 09:39:57PM

First, you don't need to set up the Root password -- just sudo, and use your regular password to authenticate as an Administrator.

Second, you can write a brief shell script to run the necessary commands, and sudo cron to make it all come out right....

Be seeing you,

Ted

---
Support Consultant - Mac Specialist, OpenLink Software

[ Reply to This | # ]

Root password needed?
Authored by: greed on Jun 02, '03 10:36:03AM

And you can always add something like:

username ALL=(root) NOPASSWD:/usr/sbin/diskutil

to your "sudoers" file. (See visudo and sudoers manpages for more fun. I mean detail.)

Then you can "sudo diskutil" when logged in as "username" without having to enter the password.



[ Reply to This | # ]