Yesterday, I had what may have been Sierra’s answer to the kernel panics in El Capitan: what I can only describe as a near-panic and soft spin. It is not something that I have experienced before in my 32+ years of using computers, of which 27 or so have been using Macs.
It happened when I was backloading articles from this blog into MarsEdit. When it is doing this, MarsEdit shows a couple of busy spinners, but everything else is normally fully responsive. On this occasion, those spinners froze, but the clock continued to tick. Shortly after that, the menubar clock seemed to freeze, then just ticked intermittently, every minute or two.
My iMac didn’t freeze, though. In El Capitan, one of the earliest and more obvious signs of a panic was that my trackpad stopped working: there was no click, and the pointer was frozen. Now, in Sierra, although the pointer was clearly struggling, much of the time the trackpad retained control over it, and its click still operated. Even the clock continued to update every minute or so. I could bring windows to the front, but keystroke commands were not effective.
After a few minutes, it seemed that I would not regain control, my iMac was crippled and unable to recover, but neither would it give in and restart itself. It was as if the kernel was fighting to keep everything going, neither able to do so, nor prepared to give in and panic. After a few more minutes, I gave in and forced it to restart.
With Console 1.0, there was precious little post mortem examination available to me. Browsing system.log just told me that a succession of spindumps had occurred – macOS creates these automatically whenever the spinning beachball cursor appears – but gave no other useful clues as to why. It was here that I sorely missed the old version of Console. With that I could have scrolled back to the period when my Mac was near panic, and running glacially, and seen just what was going on at that time, which part of macOS was broken, perhaps even why and how.
If Console 1.0 has limited value, which tools can you rely on?
You can still reset the SMC and NVRAM as detailed here, and run Apple Hardware Test or Diagnostics (according to the model) as explained here. Third-party hardware tools should also continue to work properly.
If you suspect a problem may relate to damaged or stuck preference settings, then I have put together a listing of their locations for El Capitan here. I will soon produce a version for Sierra, but in the meantime that should locate the majority of the important settings files for you.
iCloud problems are very difficult to deal with. Apple’s online service status allows you to distinguish problems in the service, which is helpful, but beyond that you are probably best calling Apple Support services, particularly when Sierra is so new. I provide some other clues here, although I will be updating that for Sierra in due course.
The advanced diagnostic tool sysdiagnose is available in Sierra. It tends to produce an excess of output, and it will quickly baffle many, but can be useful at times. Activity Monitor works much as before, and seems reliable still.
Bluetooth tools are now a feature of Apple’s SDK Xcode version 8, which has a Bluetooth packet logger and Bluetooth Explorer. It is free from the App Store.
Third party tools which have been updated for Sierra can also be helpful. On the security side, I recommend Objective-See products, which can also be used to explore loaded kernel extensions and other resident software: look at KnockKnock, TaskExplorer, and KextViewr, for example.
If you have had positive experiences with other tools and techniques in dealing with Sierra and its problems, please comment and share.