I have given up trying to blame the cat: she was asleep next to me in bed at the time. Roughly an hour after I went to bed last night, my iMac froze again. This was the first such freeze since I had updated to El Capitan 10.11.5, and I was rather hoping that the update might have fixed the issue. I am deeply disappointed that it has not.
What was unusual this time was that my Mac did not really get up and running properly again afterwards. It should have restarted automatically (it did), run through the boot process until it got to the login stage, then sat humming tunes from Frozen quietly to itself until I got up and logged in.
When I did get up and log in, it was obvious that it had spent the last seven hours or so scrawling thousands of errors and warnings into the logs instead – so many messages that the restart, timed at 00:41, had run off the top of the 4000 message All Messages buffer in Console. Those messages were not just endless repetitions of the same complaints, but a cacophony from almost every component in OS X. It was seriously screwed.
I had to take this seriously, so got my USB mouse and keyboard, hooked them up, and restarted with the D key held for diagnostics. These seem to have changed a bit with 10.11.5, or perhaps I have just forgotten what they used to look like before. The iMac checked out fine, anyway. I restarted in Recovery mode (Command-R) and ran Disk Utility, which seemed as happy as Larry too.
There were only two possibilities left: OS X remains broken, or I still had a third-party extension or something else which is triggering these freezes. I have already carved out as much of the old cruft, such as old kernel extensions, which I could find, but thought it best to have another go at cleaning the Library folders. If only SIP and its siblings were more interested in stability than mere security, and the two are not unrelated either.
My aide this time was EtreCheck, free from Etresoft’s site, which performs a thorough survey of extensions, daemons, and all sorts of other things which can cause such issues. The only surprises were Soundflower and Wacom kernel extensions which looked fairly up to date, but served no purpose, so have been excised now.
Last night’s freeze left few clues as to why it happened. A lot of those suffering from these sporadic crashes have been blaming Safari, and OS X Daily has suggested a workaround in which you disable WebGL in Safari’s Security tab of Preferences. Safari wasn’t running at the time, and even the cat couldn’t have been browsing for mice.
The restart did, though, occur at the time that my Mac should have been putting its system, but not disks, to sleep. It could therefore have been a crash on sleep problem, something far more unusual than crash on wake – when your Mac wakes from sleep, a lot of low-level software kicks in, and can readily collapse in a snotty heap; system sleep should be a far more innocuous process.
Another glitch which has started to both irritate and puzzle is that 10.11.5 seems to have Bluetooth connectivity problems. Every so often, my Magic Trackpad 2 drops out, worrying me that the Mac has frozen, only to reconnect a few seconds later. That did not happen when it was new and El Capitan was ‘less mature’.
A lot of vociferous users are getting frustrated with these sporadic crashes, particularly as they are most common on more recent and more expensive models. It is ironical to think that this iMac17,1 replaced a much older iMac which regularly ran Yosemite and El Capitan continuously for several weeks, until I remembered to restart to flush out old caches and junk. So much for progress and the attraction of newer and better.
Part of their frustration is that affected users feel that, because they have no way of reporting their problems to Apple, no one knows of these freezes. In fact, Apple is only too painfully aware of the problem, and is being swamped with crash reports. Unless you have disabled the feature, every time that there is a crash or freeze like this, your Mac sends crash logs direct to Apple. This morning, for instance, my logs contained these lines:
24/05/2016 08:20:07.293 SubmitDiagInfo: Submitted problem report file:///Library/Logs/DiagnosticReports/awdd_2016-05-23-022951_Howards-iMac.awd
24/05/2016 08:20:07.344 SubmitDiagInfo: Submitted problem report file:///Library/Logs/DiagnosticReports/awdd_2016-05-24-000551_Howards-iMac.awd
24/05/2016 08:20:08.050 SubmitDiagInfo: SubmitDiagInfo sucessfully uploaded 199 diagnostic messages
So somewhere in Apple there are systems which are crunching through all these problem reports, trying to make sense of them.
I finish with one of the weirdest features of this episode, something that I have never seen before in any logs – timestamps out of order. Here are some consecutive entries from early this morning:
24/05/2016 07:48:12.000 kernel: STEX : setPowerState : 0, (0 = sleep , 1 = pause, 2 = wake)
24/05/2016 07:48:12.000 kernel: STEX : Going to sleep, outstanding IO = 0
24/05/2016 07:48:12.000 kernel: STEX : setPowerState done
24/05/2016 06:49:42.000 kernel: AppleThunderboltNHIType2::waitForOk2Go2Sx - intel_rp = 1 dlla_reporting_supported = 1
24/05/2016 07:48:12.000 kernel: AppleThunderboltNHIType2::waitForOk2Go2Sx - retries = 30000
24/05/2016 07:48:12.000 kernel: Wake reason: XHC1
Even my Apple Watch can’t do that.