Power Manager 4.5 introduced the ability to trigger actions just before the computer sleeps. This often requested, but long denied, trigger is now available.

Compared to other triggers, the sleep trigger is not technically complex or challenging. Power Manager is informed the computer is about to sleep, and so can diligently trigger events as needed.

So why the reluctance to include the ability to perform actions on sleep? We want Power Manager to be consistent, predictable, and reliable. The sleep trigger is not an ideal candidate for these characteristics. In an ideal world, it would not be required. Nearly all actions that might be triggered by sleep, should instead be triggered when the computer powers on.

The problem is a fleeting sliver of time. The useful time between Power Manager learning that the computer is about to sleep and the time when the hardware begins sleeping is short. This moment lasts just a few seconds.

Allowing your events the opportunity to inject a series of actions into this moment is risky. There is a good chance your actions will not finish – or not even begin – before the hardware falls to sleep. Worse still, your event’s actions may cause the computer not to sleep at all. There is a degree of uncertainty in what will happen. More concerning is that what works once may not work every time.

What you want is clear. You want your event to trigger just before sleep, perform a series of actions, and then have the computer fall gracefully to sleep. This would be ideal but it is not possible.

Script Limitations

The problem lies with the actions. Power Manager and the computer have no way to know how long those actions will require. We also have no way to tell the computer how long they will take. Instead we need to rely on your judgement and caution.

Whatever actions you want to perform just before sleep must be quick. Tasks such as unmounting storage or stopping a process are fine. Quick, simple, scripts are acceptable.

Absolutely no user interaction must be triggered by sleep. You can try but it is better to trigger such interaction when the computer wakes up (powers on).

Avoid writing to disk or causing hardware to spin back up to life. While your sleep triggered actions are happening, other parts of the computer will be preparing to sleep.

Hardware Interruptions

There is a second problem to be aware of. It is possible for the computer not to sleep, even after the sleep notification has been issued. This might occur when a piece of hardware receives the sleep notification but tells OS X to interrupt it.

By the time the interruption occurs, other processes like Power Manager may have been informed and begun acting upon the pending sleep. If this happens, your sleep triggered actions will begin but the computer will not sleep.

This situation is rare and increasingly so. Hardware has become much better at supporting sleep states on OS X. However, if the situation does arise, OS X should issue a corresponding wake notification to those processes it told it would be sleeping.

Solution for Some

Given these problems and the uncertainty the sleep trigger introduces, why add the sleep trigger now?

The reason is persistent and shows no sign of going away. A sleep trigger solves a distinct class of problem. These problems occur because entering sleep still catches some processes and hardware unaware. The most common example is when a storage device does not unmount properly before sleep; on powering back on the computer complains about having unsafely ejected the disk. It is this situation that a sleep triggered script can help. A script can address the hardware weakness and unmount the drives safely.

So now we have a sleep trigger in Power Manager. For good measure, we included the corresponding await sleep trigger. The same constraints and recommendations also apply to this trigger.

Please use the new sleep capabilities carefully. If you are unsure or encounter problems, get in touch and we can help suggest approaches or alternatives that may be better.