Jan 26, '04 08:30:00AM • Contributed by: iixhd
[robg adds: I concur - this hint is experimental and potentially dangerous. I haven't tested it, nor do I have any intention of doing so! However, if spurious disk activity really bothers you, read the rest of the hint for some advice on how to remove at least one source of activity...]
To stop writing to this file:
- Go into the Finder and use the menu command "get info->ownership and permissions". Change the the owner to the current user and allow read and write access on the directory /private/var/db and the file /private/var/db/SystemEntropyCache. Note the original settings before making changes.
- 2: Go into the terminal and type:
cd /private/var/db rm SystemEntropyCache ln -s /dev/null SystemEntropyCache - Change the permissions settings on the directory /private/var/db back to their original values. Also try to change the permissions settings on the new symbolic link called SystemEntropyCache back to their original values. In my case for that link, the get info dialog box would ignore attempts to change the owner.
My computer was tested after making these changes. It takes about 10 minutes for the spinning hard drive to spin down. It did not spin up after 2 hours 10 minutes, at which point I manually spun up the drive by opening a file. This was much better than having the hard drive automatically spinning up every 60 min.
Additional notes:
I noticed a process was writing to SystemEntropyCache by using the Finder search to find items of "all" visibility that were modified "today" on the boot volume. I locked the file and changed all of its permissions to "no access". The next hour when the SystemEntropyCache was due to be written, another process spun up the hard drive and updated the /private/var/log/secure.log file.
The secure.log file read (after changing permissions to allow reading):
Jan 13 10:59:42 xs-Computer /System/Library/CoreServices/SecurityServer:
error writing entropy file /var/db/SystemEntropyCache
The computer would then try to write to the SystemEntropyCache every ten minutes. The log file was continuously updated with a new attempt every ten minutes, even after locking and preventing access to the log file. The hard drive did not seem to spin down at all.
Symbolically linking /private/var/db/SystemEntropyCache to /dev/null allows the computer to think it is writing to a file, but the hard drive is never activated because /dev/null is an empty space. Doing this does not break any security features of the OS that I know of. As normal, I was able to: log in, log out, authenticate to do things that require an admin user, and authenticate to access encrypted disk images.
I thought about symbolically linking to a real file with proper permissions on a ramdisk. However, I have found that one way to make the 10.2.8 Finder crash repeatedly is to use the Find command with visibility = all and date modified = today on the boot volume while more than one volume is mounted. I use the Finder Find on the boot volume a lot, so that was not an option for me.
Note that this is just one of many files on the hard drive that is periodically accessed by the computer. You should remove or disable other calendar apps (iCalhelper: inside iCal) and scheduling processes (cron) in order to make sure that your hard drive does not spin up. However, the preinstalled cron processes and iCal may be useful to you. Also note that the SecurityServer will try to write to the SystemEntropyCache every 60 minutes from when it was last successfully written to, not necessarily on the hour.
