Sleep Wake Failure with High Sierra 10.13.2

It has been a while since my first intention to attempt an assessment of apple’s power management settings (PMS) in relation to the SWF problem. In the meantime, forced by desperation, I went for a Beta update, following Procladius' suggestion that it seemed to do away with the SWF reboots. The good news is that it did make a difference and since I installed the 10.13.5 beta, about a week ago I have not had a single SWF event! The reason I am not calling in with jubilation is that the change is not entirely convincing. Firstly, as mentioned by jabesse, I have not enabled ‘disksleep’, which may have ruined my hopes. However, I experienced the innumerable SWFs while my ‘disksleep’ was off, so the situation with the Beta update is still (if only partially) different.

In short, it appears to me, that the 'computer sleep' mode is no longer the same as before the HS upgrade. I am not a computer expert and have no means of determining whether and to what extend the system goes into what is defined as ‘sleep’. Such definitions are not provided clearly enough for a user to be able to determine their effectiveness.

This post may become somewhat overly extended, but I hope it provides an informative overview of possibly useful PMS options.

For a start, the iMac I use allows three parameters to be set from the ‘System Preference’ -> ‘Energy Saver’ options:

- Computer sleep (from 1min to 3h to Never) - set to 10 min at present

- Display sleep (from 1min to 3h to Never) - set to 5 min at present

- Disk sleep - circumstantially (on/off), currently off.

These are part of a bigger set, available with the Terminal command, pmset -g, as given below:

System-wide power settings:

Currently in use:

standby 0

Sleep On Power Button 1

womp 0

halfdim 1

hibernatefile /var/vm/sleepimage

powernap 0

autorestart 0

networkoversleep 0

disksleep 0

sleep 10 (sleep prevented by sharingd)

autopoweroffdelay 14400

hibernatemode 0

autopoweroff 1

ttyskeepawake 1

displaysleep 5

standbydelay 4200

Although not immediately evident from the parameter names, Computer sleep and Display sleep are recognisable by the 10 and 5 min settings respectively. Leaving aside Display sleep, as unlikely trouble maker, it is interesting to notice that in addition to Computer sleep there are four other similar parameters, namely - standby, disksleep, hibernate and autopoweroff.

The setting of ‘disksleep’ is either ‘off' or ‘on' (when possible). Hypothetically, SWF could have been caused by demand on the disk, while it attempts to go to sleep, but this setting has been ‘off’ almost all of the time on my computer, while SWF has been occurring daily over the past four months.

Similarly, ‘autopoweroff' also seems to be unlikely culprit, as it powers down the computer after the 4 hours, set with the ‘autopoweroffdelay’, which in my case has been happening without signs of malfunction.

It then appears that the remaining three parameters, (computer/system) sleep, standby and hibernate may be somehow involved in SWF, given their interdependence, according to definitions. Starting with ‘standby’:

Apparently ‘standby’ effects hibernation after the machine has slept for a specified period of time. At the same time

On one hand standby should activate hibernation after the computer has slept according to the ‘sleep’ timer (set by the user), on the other, the activation should not happen before the time determined with ‘standbydelay’ (set by default to 1h10min on my iMac). On the face of it, the above should not be a problem as ‘standby’ is set to 0 (off) by default and does not seem accessible via the ‘Energy Saver’ controls. The twist, however, seems to be in the definition of hibernation.

In my case, which I suppose is not uncommon, standby and hibernate happen to be set to 0 (off presumably), the autopoweroff, however, is set to 1 (on) and it does come into effect every day for my computer (typically overnight or when I'm away for hours). Since not all three are set 0, it seems, according to the definition, that hibernate is not disabled completely. Even though hibernate is set 0 it obviously happens when autopoweroff is effected!

Conceivably, under certain combinations of sleep conditions hibernation is attempted, while it is not provisioned for and perhaps unrecognised apple system panics lead to those darn SWF events.

To wrap up, after upgrading to 10.13.5 beta my iMac has not experienced SWF, but it seems that computer sleep never takes effect, until time comes for autopoweroff, which appears to be trouble free. People have reported in the past that, when system sleep is set to ‘never’, SWF in some cases does not happen, but this obviously is only masking the problem, not a solution.

Still Waiting for a convincing completion of this dreadful episode of macOS High Sierra update.

I set hibernatemode to 3, after which my system kept running fine for quite a few days. Then, a new build of the beta arrived, and I started seeing the problem again. Just now, I went to see how things are set: hibernatemode was back to 0! I set it back to 3, and now we wait...

What a load of crap. The fact that we are all having to endure this with no official response from Apple's support is an absolute trash reflection of this company today. We should not have to meander through all of these suggestions in order to have a functioning machine.

Just found this thread after suffering for 2+ months.

Constant crashes during sleep on both a brand new MacBook Pro with Touch Bar and a brand new iMac.

Both running 10.13.4.

Just saw that 10.13.5 is available. Going to give it a shot now ...

It's been a few months now since I had this issue, but I wanted to be sure it's not coming back a week or two later.

This will probably not be the case for all, but for me, this was triggered somehow by the Bluetooth.

I've now been turning off the Bluetooth before sleeping my Mac. I have a USB mouse connected and I use it to turn the BT back on after waking the machine. That is an ugly workaround, but I did not have this sleep crash for over two months now.

Again, some people reported that the issue happened to them with the BT off but in my case, it looks like it's preventing this crash.

A couple of days ago I updated my iMac to macOS 10.13.5 and today has been the first real day that I have been able to try my Mac since the update. I switched it on this morning at 8am and then put it to sleep and then this afternoon I woke up my iMac and for the first time everything worked without any issues. My iMac still wakes from safe sleep mode but this I can deal with but after it did it's thing, everything all worked OK and I did not get any sleep wake failure error message.

Currently I do not allow any bluetooth device to be used to wake my Mac up from sleep, I will re-actavite this feature soon and try it again. I'm not yet holding my breath that it might be fixed but at the moment it's defiantly looking slightly better.

I'll post again once I have switched on the bluetooth feature.

My iMac has been in safe sleep mode for most of today and I have just woke it up and everything has all worked ok with no error message. I'm going to leave it in sleep mode over night and see what it does in the morning.

So much for my desperate hopes the SWF saga would be finally over. Unfortunately, I did not have to wait for iDeMi's reply. After a month with the .5 beta without any problems, the dreaded double-chime of the SWF reboot returned. This is only a quick recap for the sake of continuity.

My hopes were quietly propped up by the lack of the usual daily notifications from the two SWF threads. Since people generally write more about problems than they do about the absence of such, it seemed there is a faint chance the solution might have been found, at last. Looks like it hasn't.

It should be pointed out that there definitely is a difference after the .5beta update in my case, at least. It has been a great relief that for a month my work was free of the daily SWF reboots, which I had mercilessly experienced for months before that. However, as I already mentioned in my first post .5beta update comment, it did not seem very convincing that a complete solution has been found, because the sleep state appeared different and not going to a hibernate-like mode.

For the sake of completeness, it has to be clarified that during all this time I always left the iMac to follow through the power management set period of display and computer sleep (5/10 min). Yesterday for the first time I used the 'apple menu' sleep command, which I used to do in the long distant past, before the SWF plague. It could have been coincidental, but having used the 'sleep' command combined with the passing of the arriving of 'autopoweroff' state, which most certainly invokes hibernation, appears to have caused this horrible SWF again, after otherwise uneventful and so much hopeful month.

Such a disappointment!

10.13.5 seemed to have fixed my problems... I was occasionally getting SWF, but mostly my iMac27 2014 would just shut down overnight mysteriously with nothing in the system log to indicate that it even happened. In the morning I would get a double-chime as it seemed to boot twice. I believe it is a related problem to SWF which is why I'm posting here.

I upgraded from El Capitan to High Sierra about a month ago. Ghogoh's post on the sleep settings in terminal helped me figure out a solution a week or so ago—setting "standby" and "autopoweroff" to 0. I was finally able to sleep normally without an overnight shutdown. So thank you for that!

Upgrading to 10.13.5 early this week and things seemed fine the first night, so I tried "Restore Defaults" in the Energy Saver panel and confirmed in Terminal that standby and autopoweroff had returned to 1. The last 2-3 nights I've successfully woken from sleep in the morning! My problems seem solved!

Before, I was occasionally getting SWF. I *think* it was triggered if my machine had been asleep for 3-4 hours. So about the same as my standbydelay setting (10800). And maybe the autopoweroffdelay (28800) was causing the shutdown? Not sure as terminal activity seemed to point the shutdowns as happening after 5-6 hours. I have filevault enabled so I would wake to a login screen, but after entering my password the machine and mouse pointer would freeze. I had thought maybe it was related to my older madkatz mouse drivers, or maybe old Adobe updaters (I have various versions back to CS3 on my machine). I spent a lot of time cleaning out old Adobe stuff, but I think it was just a system problem as the update seems to have solved it.

So that's my info. Maybe part of it will help someone.

Pleased to read that things have started to look promising, Stitchy. Glad that some of my efforts have been of help. Thank you for your kind mention. Your comment is the closest to my understanding of the problem.

We may not be out of the woods yet, as I think that the 10.13.5 version may have only modified the 'sleep' state, so that hibernation now takes place only when autopoweroff is effected (typically after about 3-4 hours). This may only reduce the probability of processes clashing, as there is more chance for most completing, which could have been an issue with an earlier hibernation effect.

All this, of course, is still hypothesising before time or apple confirms the results. We hope.

My MacBook Pro (mid 2010) is connected via the power adapter. When I change the power adapter "Computer sleep" to 1 hour, my MBP crashes with a "Sleep Wake Failure". Below is the first few lines from the system crash report. As you can see in the report, my MBP runs the latest OS version. This Sleep Wake Failure does not happen when I disable sleep by setting the "Computer sleep" to "Never".

Date/Time: 2018-06-14 19:52:57 +0200

OS Version: Mac OS X 10.13.5 (Build 17F77)

Architecture: x86_64

Report Version: 26

Data Source: Stackshots

Event: Sleep Wake Failure

Duration: 0.09s

Steps: 9

Hardware model: MacBookPro6,1

Active cpus: 4

Looks like we have arrived. Considering the comments drought of recent, my conclusion is that SWF appears to have been resolved for most affected here. Most likely with the 10.13.5 update of HS. Well, it looked frustratingly remote and unclear as to how we get here but here we are.

My iMac has not experienced a single SWF since the 10.13.5 update, which can cautiously be accepted as resolved. It remains unknown what approach has been taken to provide the solution. In particular, whether any compromises have been made to power management and the system 'sleep' state.

Although I have no proof (as I had not been able to predict the months of SWF suffering, before it happened), it seems to me that before the dreaded 10.13.2 HS update there were two different states of 'sleep' - one, the 'hibernate' on 'autopoweroff' and another, intermediate one, where the computer will still wake up from a memory image saved to the persistent storage, going through the 'grey-screen-with-a-progress-bar' resume process, but somewhat quicker than the wake from an 'autopoweroff' state. Now it is not possible to be certain and will remain unknown, unless a good-natured apple source, confirms or denies it.

Nevertheless, it is undoubtly a huge relief and I can only be grateful to anyone at Apple who has contributed to resolving this problem, although I am not yet ready to forgive all those who refused to acknowledge the existence of the SWF issue for such a long time, even with at least a hint of an official statement, if they did not want to admit it publicly.

PS

It still remains to be seen, if there would not be any residual trouble for users, who might wish to change their 'standby' and 'hibernate' settings, which should not happen, for as long as these are perfectly normal options to set.

This is really bizarre. I have not experienced a single SWF for two weeks after updating to 10.13.5. This is in complete contrast to the SWF reboots I had every day for months before that. Extended comment follows ...

Sorry to say that I just discovered this topic because this problem (which I had never experienced before) started for me AFTER I upgraded my iMac 2012 to High Sierra 10.13.5 recently. I'll describe it briefly, since it could be a new iteration of an old problem, or a new one: I can wake the Mac up from "sleep," with the keyboard (which is wireless), the desktop appears and, while nothing's missing, everything is "grayed out," and it takes about 45 seconds to a minute before the color returns. (Because it's Pride Month, I think of this as my computer waking up in Kansas and then taking a while to get to Oz.) At which point, my bluetooth mouse is not recognized. I can fix that by turning the mouse off, and then turning it back on, but this won't work unless I wait about a minute to 90 seconds after the color returns.

Bottom line? A wake-up function that used to take perhaps 2 to 3 seconds now takes about 2.5 minutes. So, it looks like Apple didn't solve this problem. Maybe they decided to spread it around more broadly so they can claim it's a feature rather than a bug?

I actually was considering buying a new iMac, but I've put that on hold. If this kind of thing is going to be a regular occurrence, I may go back to Windows. It's so buggy and crashes so much that users having to dive into the code to fix things is both expected and accommodated. With a Mac, you're just kind of stuck with whatever Apple gives you, which is generally nice, but does sometimes look astonishingly like the flip of a middle finger.

Logan, from your description, what you're seeing is a "feature" called "Safe Sleep". After a certain period of time, the machine wakes in order to offload the contents of RAM to disk. Upon waking, RAM is restored from disk, hence the extended period of time before the machine is responsive.

Were I to guess, it's this feature that is causing the occasional "Sleep/Wake Failure".

A temporary workaround is to go to System Preferences-> Energy Saver and enable "Power Nap". This keeps the machine in a semi-awake state, preventing Safe Sleep and (at least for me) eliminates the Sleep/Wake Failures that were a regular occurrence with Power Nap disabled.