[Update 15-Mar-08: Anyone wishing to modify their Mac's safe sleep settings should use Patrick Stein's SmartSleep preference pane instead of the script below; see "SmartSleep Solves Safe Sleep Situation," 2008-03-15. -Joe Kissell]

My recent article "Stewing Over Safe Sleep" (2007-07-30) seems to have touched a nerve. It provoked lots of discussion on TidBITS Talk, not to mention numerous email messages, prompting me to write a follow-up post on my personal blog. Now it seems that even the follow-up needs a follow-up, as new information has emerged and various helpful hints have been offered. Here, then, is the rest of the story (or as much of it as I know at the moment).

A Quick Review -- In Apple's current implementation of Safe Sleep, simply putting your laptop into (ordinary) sleep mode triggers it to save a copy of your RAM onto disk - taking up as much as 4 GB of disk space and delaying the onset of sleep by as long as 49 seconds (depending on your laptop's configuration), during which, Apple's documentation cautions, you must not move your computer. The RAM is cached so that if, later on, your battery drains completely, you can return to your previous state quickly (a bit slower than waking up from ordinary sleep, but much faster than restarting), without having lost any unsaved work. This default setting can be modified only by mucking around in Terminal or with third-party hacks. If you don't like waiting almost a minute before moving your computer every time you put it to sleep (and I certainly don't), you must go to considerable effort to change that behavior.

When Safe Sleep Is Good -- In my earlier article, I complained that cases where Safe Sleep would actually be valuable are rare, at least for me, making it all the more irritating that saving RAM to disk is the default. However, several people pointed out usage scenarios in which someone might be delighted to have a copy of their RAM cached to disk, even if it meant taking a minute extra for their laptop to sleep. Although I may not encounter these situations myself, I grant that they make Safe Sleep more useful. A trans-Pacific flight during which you might burn through several batteries, for example, is a good time to have Safe Sleep available. The same is true if you know your laptop's battery is easily jostled out of place (losing electrical contact and thus depriving your computer of power) during travel to or from work.

Another good example: swapping batteries. If I put my Titanium PowerBook G4 to sleep, I can swap batteries (even without an AC adapter attached) and not lose the contents of my RAM. However, some Mac laptops (including the new MacBook Pros) lack any sort of short-term power supply that can enable a live swap like that. With these models, if you can't connect an AC adapter or put them into Safe Sleep, your only other alternative is to shut down completely before changing batteries and restart afterward - quite a hassle, not to mention a step backward in usability. (One could even imagine that the Safe Sleep feature was someone's idea for saving a few cents on hardware components - why have extra parts to preserve the RAM when we can accomplish the same thing in software? - but I sure hope that wasn't the case.)

In addition, a number of readers mentioned that if your battery drains completely without a RAM cache being created, you'll lose more than unsaved documents. Window and palette positions, the contents of the Clipboard, open tabs in your Web browser, and various other things might disappear too. Even the time required to restart and open a bunch of applications again can be a drag, and recovering from Safe Sleep is much faster, even if you've previously lost some time waiting for the RAM to be saved to disk.

So on the one hand, there are times when a typical user might greatly benefit from Safe Sleep; on the other hand, during periods when you know you won't need it, it's still preferable to be able to put your computer to sleep instantly (and save a few gigabytes of space on your hard disk). And although you could enter commands in Terminal whenever you wanted to switch modes, that's not very convenient. Greg Nicholson emailed me with a solution he uses, which I thought was quite clever. He has cron run a shell script every 10 minutes. But unlike the simple script I provided in my earlier article, Greg's has some smarts: it does different things depending on your battery level. If your battery is running low, it turns hibernatemode on, so that when your computer sleeps, it will save the RAM cache. But when your battery level is high enough again, it turns hibernatemode off and deletes your RAM cache. That way, you can have the best of both worlds, more or less.

My version of Greg's script follows; you can change the values 30 and 50 (as in, activate hibernatemode when battery level is less than 30 percent and deactivate it when battery level is over 50 percent) to your preferences.

#!/bin/sh
MODE=`/usr/bin/pmset -g | awk '/hibernatemode/ { print $2 }'`
LEFT=`/usr/bin/pmset -g batt | grep Internal | awk '{ print $2 }' | awk -F % '{ print $1 }'`

if [ $LEFT -lt 30 ] && [ $MODE != 3 ] ; then
  {
     /usr/bin/logger -t "hibernatemode" "Battery level less than 30%; setting hibernatemode to 3"
     /usr/bin/pmset -a hibernatemode 3
  }
elif  [ $LEFT -gt 50 ] && [ $MODE != 0 ]; then
  {
     /usr/bin/logger -t "hibernatemode" "Battery level greater than 50%; setting hibernatemode to 0"
     /usr/bin/pmset -a hibernatemode 0
     rm /var/vm/sleepimage
  }
fi

As with any shell script, you must save this as a plain text file and make it executable. One way to do that is to type:

sudo chmod ug+x your-script-name

In addition, if you plan to use cron to schedule this script to run automatically, bear in mind that it requires root privileges. My own solution is to put the file in my system crontab (in which all scripts run with root privileges), but a safer tactic (and the one Greg recommends) would be to add the following to your /private/etc/sudoers file:

ALL ALL=(ALL) NOPASSWD: /usr/bin/pmset -a hibernatemode 3
ALL ALL=(ALL) NOPASSWD: /usr/bin/pmset -a hibernatemode 0
ALL ALL=(ALL) NOPASSWD: /bin/rm /var/vm/sleepimage

Safer still would be to replace the first ALL in each line with your short user name.

A Question of Encryption -- In my earlier article, I mentioned that when changing the hibernatemode setting manually, you should use a value of 0 to turn it off; 3 to return it to its default state (on only when needed, but always save the RAM state when sleeping); or 1 to make your computer use Safe Sleep, rather than ordinary sleep, all the time. Then I went on to say, "And if you have Use Secure Virtual Memory selected in the Security pane of System Preferences, replace the 1 or 3 with 5 or 7, respectively." That last sentence, it turns out, was not merely mistaken but a very bad recommendation indeed. Please forget that I suggested it. Don't ever use 5 or 7.

Ordinarily, when Mac OS X uses virtual memory (VM) - temporarily storing a portion of your RAM on disk - it writes out the data unencrypted. The problem with this is that if your RAM happened to contain something confidential, such as a password, then even after you shut down your computer someone could extract that data from the VM swap file on your disk. Security experts regard this as a huge risk, and recommend that virtual memory always be encrypted when written to disk. In Mac OS X Tiger, you can do this by opening the Security pane of System Preferences and checking Use Secure Virtual Memory. (In fact, everyone go do this right now. I'll wait.)

How does Secure VM relate to hibernatemode? Well, with hibernatemode settings of 1 or 3, your RAM is saved to disk according to the Secure VM setting you're using. So, if Secure VM is off, a setting of 1 or 3 writes your RAM cache unencrypted, whereas if Secure VM is on, a setting of 1 or 3 encrypts your RAM cache. That is as it should be.

Once upon a time, however, when hibernatemode was new, it didn't work correctly with Secure VM. So the 5 and 7 settings were added to *prevent* your RAM cache from being encrypted even if Secure VM was turned on! That problem, however, was short-lived, and now that modes 1 and 3 work as they ought to, you should avoid using 5 or 7, which would effectively eliminate the value of Secure VM in the first place.

Suppose, however, that you not unreasonably took my earlier advice and thereby unwittingly wrote an unencrypted RAM cache to your disk - or that you never had Secure VM turned on in the first place and have an unencrypted RAM cache for that reason. Merely erasing that sleepimage file won't overwrite its contents; any moderately skilled hacker could still read its contents quite easily. So instead of issuing this command:

sudo rm /var/vm/sleepimage

use this one:

sudo srm -s /var/vm/sleepimage

The srm command is the secure version of rm ("remove"). By default, srm overwrites files 35 times (just like the most secure version of the Erase Free Space feature in Disk Utility). And that's definitely secure, but it also takes forever, and probably has no practical benefits for most of us. The -s flag is for simple security - a one-pass overwrite - which should be adequate for most ordinary citizens. If you prefer to be more cautious, you can replace -s with -m ("medium") for a 7-pass overwrite.

Note, however, that if you're running a script (either Greg's or mine) to turn off hibernatemode when needed, you need not use the srm command in that script. The reason is that when hibernatemode turns on, it creates a blank sleepimage file. Although that file is as large as the amount of RAM you have installed, it contains no data until your computer enters sleep mode. So as long as your script catches it and deletes it before your computer sleeps, you need not spend the extra time to overwrite a blank file securely.