More often than not, we’re left wondering what caused a problem. If you’re lucky, something specific might reveal itself, but in many cases we’re forced to try out our repertoire of generic solutions. These have changed with the Signed and Sealed System Volume in Big Sur and Monterey: not only is reinstalling the system very unlikely to do much good, but there’s no option to install the current Combo updater, as updates either come through Software Update or in the full installer. This article looks briefly at what are still available and effective, starting with the quickest and least disruptive.

Kill the process(es)

If you’re able to identify one or two misbehaving processes, then some advanced users like to kill them in the hope that will fix them. For an app which has gone haywire, this is simple using the Force Quit feature (Command-Option-Escape), which is an excellent way of restarting the Finder when that gets broken. Faceless processes can be killed in Activity Monitor, although most who seem to enjoy this solution prefer to murder them using kill in Terminal.

Where the process is a macOS service, it will normally be restarted automatically. However, you need to understand the consequences of your actions, as sometimes you could kill something crucial and make your problems worse. So if you don’t know what that process does, and what else depends on it, you shouldn’t be doing this. And if you’re blindly following what someone suggested on the internet, you’re playing Russian roulette.

Log out and back in

Logging out and back in again was for a long time one of the tools of advanced users, as it quit all open user processes, then restarted them. As I’ve recently reported, this isn’t so any more: while some user processes will be started afresh, many won’t, making this considerably less successful. As it’s quick and simple, it remains a potential solution to problems confined to user processes, but don’t be disappointed if it doesn’t help.

Log out, log in as a different user

Some advanced users always keep a second user account at the ready, so they can log out and log back in as that user. If you’ve done that, it’s an excellent way to work out where the cause of your problem is. If it occurs in your normal user account but not in the secondary account, then it’s almost guaranteed to originate from something in the first user’s ~/Library folder.

This remains a valuable diagnostic strategy, which narrows down where to look, and is one good justification for keeping a second vanilla user account ready to use. But it’s a long time since it last proved useful to me.

Reboot userspace

I’m very grateful to Mikey @0xmachos for suggesting this one, which is quite often used when working with jailbroken iOS/iPadOS devices. To use it, enter the command
sudo launchctl reboot userspace
in Terminal, and authenticate. According to its man page, what happens next is that every running process down to launchd and the kernel is torn down, and launchd, the service responsible for launching everything after it’s launched by the kernel, relaunches itself to bring all other processes back up. According to Apple, “This is useful for rebooting the system quickly under conditions where kernel data structures or hardware do not need to be re-initialized.”

What happens is that your Mac appears to restart, without all the performance of a real reboot. You’ll then be invited to log in, but that’s when the problems start, as some things may not work quite right. For example, when I tried it, it was impossible to open any App Store app, as macOS appeared to be unable to run required security checks. I then ended up having to restart after all, to restore normal function, which lost any advantage to this strategy.

Restart

While some other solutions have been lost, or now have dubious value, the one which has become even more useful is restarting/rebooting, provided that your Mac runs with its System volume signed and sealed. If it does, every time it starts up, the signature and seal on the SSV are checked, and with them the integrity of the whole volume. This doesn’t say anything about the integrity of the macOS files stored on the Data volume – which includes Safari, MRT, and other important tools – but is valuable assurance.

If the seal has been broken, which could mean that the contents of the SSV have changed, Intel Macs without a T2 chip will normally alert the user during startup, while those with a T2 or M1 chip are likely to panic during startup, leading to a boot loop, which would eventually start up in Recovery mode to enable reinstallation of macOS.

Restarting your Mac remains a mainstay solution, valuable after updating macOS if that leaves the system unstable, for instance. It’s also the solution of first choice for managing memory exhaustion resulting from a system memory leak, and a whole slew of other problems.

Restart in Safe mode

In Safe mode, macOS disables all third-party extensions and launch/startup items, some of its own too, and flushes various caches. There are three excellent reasons for starting up in Safe mode:

• As a way of flushing caches, waiting a couple of minutes, then restarting back in normal user mode.
• To assess whether the disabling of third-party software resolves a problem, which would imply that software was causing the problem.
• When you can’t update or install macOS in normal mode. Apple recommends this as a fallback.

It’s generally underused as a solution, but can often fix problems following macOS updates and more. It’s easy to do on an Intel Mac, and is often engaged from a restart rather than starting up from cold, although Apple advises the latter. But this is one manoeuvre which is more trouble to perform on an M1 Mac, where you have to shut down and start up in Recovery before you can set that Mac to start up in Safe mode.

Start up in Recovery

Recovery mode is the ultimate resort for all the more serious problems, with its collection of essential tools, including Disk Utility, a macOS installer, and Terminal. It’s worth remembering that recoveryOS isn’t a full macOS, and many of the command tools you’re used to in macOS aren’t available in Recovery. However, it’s still the best place from which to check and repair startup volumes, and to reinstall macOS provided that you want the current release version.

As with Safe mode, M1 Macs have to be shut down before they can be booted into Recovery, while Intel Macs can be rebooted straight into the mode.

Restart from an external bootable disk

Many advanced users have kept a special bootable recovery disk containing a custom selection of disk repair, diagnostic and other tools. Rather than booting into Recovery, they connect that disk and restart the Mac from it. This still works fine with Intel Macs without T2 chips, and can also be used with a Mac containing a T2 chip, but only if they have already been configured to boot from external disks in Startup Security Utility.

This becomes more complex with M1 Macs, though, because much of their early boot process is performed from their internal SSD, even when they are set to start up from an external disk. If damage to the internal SSD is such that booting into Recovery isn’t possible, then it’s unlikely that the boot process will go far enough to be able to boot from an external disk. Thus using such an emergency repair disk is generally no better than starting up in Recovery. If that’s not possible, then it’s likely to require DFU mode and a restore using Apple Configurator. I have yet to hear of an M1 which was recovered successfully from an external disk, but couldn’t enter Recovery mode.

Others

For Intel Macs, resetting NVRAM and the SMC remain as useful as they ever have been, but neither is available on M1 Macs. Startup Security Utility is an essential tool for Macs with T2 and M1 chips, and an important reason for entering Recovery mode. No doubt there are other solutions too, beyond those fundamentals.