Frequent system hangs and freezes in macOS Mojave 10.14: Notes, reproducible errors, and possible workarounds

For now, I've disabled Spotlight systemwide. The most reliable and direct way to do that is to follow these steps:

1. Open System Preferences.

2. Click Spotlight.

3. Click the "Privacy" tab.

4. Add your entire hard drive (i.e., "Macintosh HD", or whatever you've named it). You can do that by (a) dragging its icon to the "Privacy" list, or (b) clicking the "+" button, then selecting it from the choose-folder dialog box.

I've done this both on the problematic Mini, and on my Air, which is a 2014 model and has not experienced any hangs. Spotlight appears to be a runaway process (see the image below to see what I mean), and SSD's have a finite read/write cycle life. Spotlight's incessant running and indexing of my drives will adversely affect their operational life, and there is no amount of file indexing which I think supersedes the operational life of my machine.

Furthermore, at the moment, Spotlight is hitting my Air's SSD so much that its battery life has dropped by at least 50%. I installed Mojave on the Air several days ago. It's only a 512 GB drive, and about 175 GB are free. There is no way it should take several days to completely index that drive.

The above is Activity Monitor's list of all processes called "mdworker" on the problematic Mini. mdworker is a Spotlight process; its task is to trawl your drive, find searchable content, and cache it.

There are 34 instances of mdworker listed here. None of them have fewer than 3 threads open. That is far, far, far too many. Spotlight is a runaway process, at least on the Mini, and I don't consider it mission-critical enough to let it trash my Air, either.

Meanwhile, the file I/O problem (copy errors on the Mini) may be the other culprit on that machine, responsible for the system hangs. Every time I copy a corrupt file, the system hangs while it tries to read it. And what do we imagine happens whenever mdworker opens a corrupt file to try to read it for Spotlight indexing, or OSX tries to move the file for defragging/optimization?

Hi, sepsus. Happy (?) Monday to you!

PathFinder … I've tried that one myself, and you're right, it does seem to perpetually be in alpha. I settled on TotalFinder a couple of years back, mostly because I wanted full-window labels/tags. It seems to be pretty stable. Of course, that one needs SIP disabled to install or run. It's always something, isn't it?

But even with TF disabled, those hangs persisted.

My own odyssey is far from over, but the Mini seems to have settled down a bit. There was a time when, after a particularly vicious little set of hangs in Safe Mode, it didn't want to boot at all. I couldn't even get Recovery or Internet Recovery to load. While I was downloading the Mojave installer to my Air and creating a bootable installer thumb drive, the Mini managed to bring itself back online, and I resumed copying the content of my home folder.

That specific set of boot problems was preceded by a console error message during restart. A photo of that message is at the end of this post.

Occasional (-36) errors continued to surface, but they remain rare, and are mostly limited to relatively recent files, and so far, only to fairly insignificant and non-system-critical ones. Curiously, the problems I saw before — the whole Mac freezing while Finder attempted to copy the corrupted file — no longer seem to be manifesting.

I've never used Smart Mailboxes in Mail, so their absence isn't conspicuous to me. It wouldn't surprise me to learn they're reliant on Spotlight, though. A few too many things seem to be.

I'm beginning to suspect an interaction (at least in my case) between FileVault, some background file I/O processes, and those few mildly damaged files. Given how I know Mojave behaves when it tries to copy a corrupted file, it's easy to imagine similar symptoms manifesting in background file-access operations.

I have yet to identify a single consistent or persistent cause of the system freezes in Activity Monitor. It's been up and updating since yesterday. It never once showed any indication that any background process had locked up.

However, at the moment, operations on this Mini appear to be smooth and normal.

It's conceivable that, after I freed up 25% of the space on the HD, OSX now has enough room to do what it needs to do with such processes as background defragging, and moving certain files over to (or off of!) the SSD portion of the fusion drive.

FileVault quirks:

The Mini has been running in normal boot for more than twelve hours now, and appears to be considerably more responsive and reactive than it was. It may have been decrypting the boot volume all last night, or it may not. I can't tell.

I can't determine if FileVault has been deactivated or not, or how far along the decryption is. The decryption progress bar is no longer visible in FileVault's window. When I directed the Mini to disable FV, it was still in Safe Mode, and decryption did indeed begin, but a few minutes later, the progress bar simply disappeared. (I turned off FV on my Air too; it took about 2 hours on that machine, and the progress bar was visible the whole time.)

Decryption appears to be a persistent state, something that resumes after system reboot. So when I finally was able to bring OSX back online, the progress bar returned to the FV window, about 2% filled in, with the estimate on the screen telling me there was "about a minute left" to finish the decryption. Not possible; it hadn't been online long enough prior to that, and there are still about 800 MB worth of system and user files on this drive.

Terminal APFS tools show the list of volumes, and indicate the boot volume is still encrypted, and do not indicate it is decrypting. Attempting to run Terminal decryption commands results in an error telling me decryption failed to start. This leads me to speculate FV is still decrypting, but not visibly, not even as a user process in the Activity Monitor window.

The only hint I have that FV's decryption may still be running is the gradually increasing number of bytes read/written in the kernel_task process. But that could also just be normal background file ops, such as optimization.

FileVault is something I've used sporadically. The original version of it created a disk image of your HD, then pretended it was a normal volume after you'd logged in. As a result, you needed to have a lot of free space on your boot volume to activate or deactivate it, so data could be swapped into or out of the disk image. (Once it was running, those space requirements weren't as important.)

The more recent version of FV is a whole-disk encryption-on-the-fly model, so adequate free space to activate it (or deactivate it) is not as important as it once was. However, after it was off on my Air, I noted an increase in free RAM of about 500 GB. That isn't especially surprising — you'd expect the process to use additional system resources — but it was more than I expected.

Summary, so far:

FV, in conjunction with relatively limited (10%) free space at time of install, in addition to post-install Spotlight re-indexing, combined with some damaged files, may have been largely responsible for my initial post-install problems.

I think it would be advisable for anyone attempting a Mojave install to do these things before installing:

1. Disable FileVault.

2. Ensure at least 20% of the destination volume is free space.

…and after install:

3. Disable Spotlight.

4. Disable all system sleep modes (turn off Energy Saver, for instance).

5. Leave the machine running (and, in the case of portables, plugged in) for at least a day.

Somewhere during that time, the machine should be able to get itself more or less functional. After it appears to be working normally, re-activating Spotlight might be viable, though I think I'd still turn it off for items such as spreadsheets, PDF's, and so on, unless text search of individual documents' content is important to a given user.

Historically, Spotlight has sometimes been a problematic service on OSX. We might be seeing that again with Mojave. It's usually fixed with the next release, so 14.1 may bring us a better-behaved Spotlight.

Things I have yet to do:

1. Finish copying my home folder.

2. Complete a TM backup.

3. Reboot.

It's possible this isn't over yet, sigh.

Error message:

Last night, while in Safe Mode, I directed the Mini to disable FileVault. It began to do so, but FV decryption progress disappeared from the FV tab in the Security preference pane. After some time (and a few freezes), I rebooted the Mini. I boot in verbose mode, and saw this final shutdown message (the one beginning "sanity_check"; the "apfs_stop_bg_work" messages appear to be standard fare with APFS).

The system appeared to lock up, and never powered down. A hard restart resulted in a normal flow of console messages at first, then a brief flash of the Apple logo (white on black) with a progress bar, but then a black screen for many minutes.

Thereafter, the Mini would boot in neither Recovery nor Internet Recovery mode. However, as I was creating a bootable Mojave thumb drive, the system eventually pulled up its socks and presented me with a normal login prompt and, ultimately, my desktop.

FV decryption reported it was continuing, but its progress bar has since, once again, vanished from the FV tab.

I have not rebooted since, am still continuing to manually copy my home folder to an external volume, have encountered a few more (-36) files, and system hangs appear to have largely stopped now.

NotUncleAl — Spotlight is a possible culprit, in some circumstances, but it turned out not to be with me.

WindowServer seems to grab a lot of memory in AM, but I'm pretty sure that's expected behavior; it's handing out windowing information to such things as AM, while the window is open, so you'd probably expect to see an increase in its activity as it refreshes its own status.

This Mini is a late 2012, with a 128 GB SSD and a 1 TB rotational disk, originally strapped together in Core Storage as a single fusion drive. Back in July, we moved halfway across the country, and along the way passed over some ludicrously decrepit interstates, with enough cratering to make it seem like they'd suffered artillery barrages. Everything in the back of the truck got jolted around, including the Mini. It wasn't until mid September that I set the Mini up again. At the time, of course, it was still running High Sierra. Then I tried Mojave on my Air. All seemed to go well, so I installed it on the Mini too, and that was when it all fell apart.

Last week I began hand-copying the contents of my Home folder to an external drive, at first using Finder, but the system hangs were making it impossible to proceed. Ultimately I executed a cp -av command in Terminal, and let it grind away. This is a lower-level process and runs in the Terminal session, so contributed a little less to freezing; but periodically I'd see Terminal hang quite a while between one file and the next, and every once in a while it threw file input/output error messages, too. I think in the end I lost about 5% of my data, but that's not bad, considering I hadn't been able to do a Time Machine backup since the Mojave install. (My documents are synced with my Air via the cloud, and virtually all my video, audio, and photo files reside on a media server, which is itself backed up across other disks.)

After wiping the fusion drive, Mojave hung on the install. I'd needed to load from a thumb drive by then; the recovery partition was no longer available, for reasons which will soon become clear. I put High Sierra on another thumb drive and tried installing that instead, and in the process of doing so, reformatted the container which held my fusion drive (oops). That had the effect of splitting the drives apart again, so Core Storage was no longer treating them as a single contiguous volume, but instead an SSD and a rotational drive, contained in the same Mini.

I reformatted them as HFS+ and rebooted back into Mojave's installer, and tried using a new command in terminal:

diskutil resetFusion

What this theoretically does is rebuild your fusion drive into its factory-ship state. It failed for me.

So I formatted the drives again, this time as APFS, and installed Mojave to the SSD, leaving the rotational drive empty. Then, once I got back into my fully-loaded desktop, I started the proctology. I did that because Disk Utility, when it was able to run independently on the 1 TB rotational drive, reported its SMART status as "Failing".

Oh dear.

Disk Utility cannot conduct a low-level format on anything. Even the secure-erase option only whacks the data on a partition; it doesn't pay any attention to empty or deallocated sectors. So there was no inbuilt way, through GUI tools, for me to do a low-level format and check the drive block by block, sector by sector. My next fallback was to get more information on the SMART status, since "failing" is not particularly illuminating.

SMARTReporter, if you don't have it, is something you should get. Even the free version is useful beyond my capacity to easily describe. It exposed more than 31,000 errors on the rotational drive, some of them more than 100 sectors in size, on a disk with less than 47,000 hours total uptime. I'm proximally certain some of those bad sectors once contained the recovery tools, which was why booting to recovery wasn't working any more.

The conclusion was plain: The physical surface of the rotational drive has been damaged, and large parts of it are unreadable now. My first guess is it happened during all the jouncing in the move.

To see how bad the damage was, I tried using this command to write 0 to every block on the disk:

dd if=/dev/zero of=/dev/disk1

…but it finished earlier than it should have, at about 940 GB of 1000 written. This suggests to me there's about 60 GB worth of damage on the rotational drive. (Don't use dd if you don't have a very good idea what you're doing; it'll overwrite anything with anything, even if you didn't want it to, simply following the commands you gave it.)

I might be able to use the command-line third-party program smartctl to build a custom table of blocks to avoid, but at this point, it's likely not worth it. If I tried that, it would just be as an experiment to see if I could.

The point is this: Particularly in fusion drives, it can be hard to spot if there's something suffering from incipient failure, and the odds are very good the Mini was in trouble before I put Mojave on it. MacOS, out of the box, does not actively poll any drive's SMART status. You either have to check using Disk Utility, or you have to get into the About This Mac > System Report… subwindows (look under "SATA/SATA Express"), or you have to install a third-party app to do the checking for you. So I have no way to know for certain when those incipient failures began popping up. I just wasn't paying as close attention to it before the install, because I was not waiting for a new install to finish, load, let me get to work, etc.

The demo/free version of SMARTReporter is here: https://www.corecode.io/smartreporter/

Its diagnostics, under the "Advanced Tools" tab of the "Disk Checks" pane, might disclose information regarding your own drives, as well. The only difference between the free and paid version of SR is the paid version will actively alert and email you if it detects impending failure; it also gives you a nag dialog at boot/login. The paid version is ten bucks.

So the rundown is this: If your Mac is still hanging a week or more after the Mojave install, even if Spotlight is off, run some low-level disk utilities on it and see if one of its drives is on the way to checking out. I don't know if Mojave is more sensitive to this kind of thing, maybe because APFS is finally in the mix across all supported systems, but it certainly does not like disk errors. It will hang, for minutes on end, even if you're not doing anything directly related to disk I/O in either the Finder or inside applications (open/save dialogs).

I have now found two ways to consistently bog and freeze my Mac. My followup here discusses what I've been seeing, and proposed user solutions. It also goes into what I think the underlying cause is.

Laggy, frozen, slow Mojave: 100% consistent methods to reproduce, discussion of possible cause, and proposed user workarounds

Thanks for the kind words.

"when you disable spotlight are you also dragging the harddrive into the privacy section of spotlight per the suggestions in the other thread?"

Yes. It puts the brakes on Spotlight for the whole volume. The advantage of using that, over a Terminal command, is you can undo it any time by getting back into the Spotlight prefs.

I'm not sure how persistent it would be to just pull the process from launchctl. It might come back on the next reboot, and remembering what you did and how to reverse it might be problematic, if you decide to bring Spotlight back online. Doing it through the Spotlight pref pane is theoretically permanent until you remove the drive from the "Privacy" tab.

Yes. It's infuriating. I feel like I'm running Windows Longhorn, for Pete's sake.

There is definitely something amiss with Spotlight, and for the time being, turning it off systemwide might be the best short-term solution, until we see 14.1.

Hi, sepsus.

I'm not sure if there's any third-party program that is designed to trawl through drives, looking for problem files. If there is, it may or may not have been updated for Mojave/APFS, and may or may not return useful results.

Corruption may be specific to my volume. I've since been able to churn through those low-priority files and remove them by copying to USB, and transferring them to the media server, which is an ancient Mini (mid 2007) but still functions well enough to feed data to Apple TV.

I can't be certain file corruption is the cause here, because now, with 280 GB free and Spotlight indexing turned off, I still have those system hangs — they're not as frequent, but they're still happening. That's a volume with 25% free space now, so we can probably rule out the idea OSX doesn't have enough free space to function. (Probably because I'm attempting a TM backup now — the last one couldn't be verified due to system hangs, so OSX has to start all over again, which means it's caching huge blocks of data to the boot volume, and therefore sucking up free space all over again.)

These system hangs have been reported by others who are using only SSD, so it's not a fusion drive specific problem either.

Some process is hanging the system. I still suspect it's related to file I/O, and the next most likely culprit is OSX's background defragmenting. This isn't a user-addressable process at all. There's no way for anyone to switch it off.

This is, by far, the worst-behaved OSX release I've ever seen, and I've been using OSX since its public beta, in the year 2000.

To be fair, sepsus, what we're seeing here is an increase in complexity in both the filesystem, and the hardware it's running on. When OSX was new, it was running on a 32-bit processor using the Motorola architecture. It's since transitioned to 64-bit Intel. Tasks have become more intricate, graphics capabilities have increased, and more user safety nets have been added, and drive technology has undergone a monumental shift away from rotational media to hybrid or total solid state. All of this has been done without substantially changing the look and feel of the operating system, or much of its user-visible behavior. Most of this has been done with an eye toward sustaining legacy users, meaning in practice the goal has been to keep our files and data safe and readable.

Some of the data on the Mini I'm having trouble with now first saw light in 2003. The system foundation it's running — and many of my files — began life fifteen years ago. I've never had to do a format-and-reinstall, thanks in part to the "Files and Settings Transfer Wizard", and to my own relative conservatism, but mostly to Apple's genuine commitment to quality of user experience.

This is one reason problems like this are so frustrating, when they happen. They just aren't that common.

It's striking, to me, you've been having problems from the outset. It doesn't do you much good for me to say, well, Sierra worked fine for me, and so did all the others … because that doesn't do anything for you. (Though I seem to recall 10.2 was a particularly troublesome release.)

We do know there are recurrent problems with Spotlight, and have been, periodically, for years. In some cases its database seems unduly fragile, and in others it seems to spawn runaway processes. Usually those problems are fixed with the next system update; ideally that'll be the case with 14.1. For now, I've decided to disable it on all my Macs, but I really never use it much anyway. That's not always so, for others.

Unfortunately, while turning Spotlight off has reduced the number of hangs on the Mini, it has not eliminated them.

If you haven't yet turned off Spotlight indexing of your system, it might be worth trying, to see if that improves performance for you. If search is important to your workflow, there may be some third-party options for you that let you do a Spotlight-like search of your HD, without all the system overhead.

Latest update. Hangs continue, with the same symptoms I've described. There are times when Finder hangs so badly, even its system clock (upper right corner of the screen) doesn't update. I've set the colon in the clock to blink, an old habit I got in long before OSX, because when that colon stops blinking, you know your system is good and solidly frozen.

Disabling Spotlight indexing reduced the number of hangs, but did not eliminate them.

Time Machine is still not able to complete a backup of the drive, sigh, even after reformatting the TM drive to case-sensitive journaled.

So I'm copying my entire home folder over instead, prefatory to doing a reinstall from Recovery. This does not necessarily need to be a destructive reinstall. You can do it without formatting the drive first. I'm just copying my data over as a backstop measure, so if I do need to format for some reason, I haven't lost anything irreplaceable.

Currently the Mini is in Safe Mode and performing the copy.

File Vault is on, by the way; it's been on for years, without any problems. I might try turning it off before I try a reinstall. If Mojave has filesystemwide encryption, File Vault should no longer be necessary, and may be contributing to some of my problems.

Corrupted files:

So far the copy has stalled twice, reporting (-36) errors on a couple of files. One was a previous iTunes library file; another was a song file from an album. Neither was particularly large. I'm deleting them as they're discovered; they're not system- or user-critical files and are replaceable.

A note for anyone else playing along: It is important to empty the Trash before resuming copying. Otherwise Finder will try to copy the contents of the Trash along with the rest of your home folder, including the corrupted files it contains.

This reawakens my suspicion there were/may still be corrupted files lurking in out-of-the-way corners on that Mini, which are preventing Mojave from working smoothly as it tries to move them for optimization, or performs some other low-level file I/O process on them.

Picking up where you left off with copying:

One nice aspect to this filesystem is that while the copy op does stop entirely until I dismiss the error dialog, I am able to resume copying (manually) where I left off by once again dragging my home folder over to the external hard drive icon. I'm asked if I want to replace, or merge with, the content already copied. I choose merge, because that is essentially resuming where it left off.

Locating corrupted files by name only:

I've got a minor challenge to face, because as the copy proceeds, Finder will likely locate other files that throw (-36) errors. Figuring out where those are might be tricky, since I've disabled Spotlight! Finder only reports the name of the file, not the folder containing it. What happens if it stumbles across one file (of thousands) in my ~/Library folder? How do I find that one file?

Terminal to the rescue, with the find command. The basic syntax is this:

find [path] -name '[name]'

If Finder tells me the file named "com.nightwares.someSettingsOrOther" can't be copied, I can locate it this way, in Terminal:

find /Users/warren/ -name 'com.nightwares.someSettingsOrOther'

When Terminal locates it, it'll tell me which folder contains it (complete with the path to that folder), so I can open that folder, trash the file, empty the trash, and resume copying.

Copying is still going on. Perhaps one in twenty or so files throws a (-36). Many of these are files created after the Mojave install, in the brief windows of time I had when the system appeared to be somewhat functional.

Meanwhile I've also directed the Mini to deactivate FileVault. There are known compatibility problems between Mojave, FV, and some third-party cards in older Mac Pro machines, and FV is about on-the-fly encryption. I'm wondering if there's some kind of unfortunate interaction taking place between FV and Mojave, which is responsible both for the appalling drive read performance, and the (-36) corrupted files.