Every stop code

MSL shows a crash screen when it has stopped and carrying on would mean pretending. Every stop carries a code — a number like 0x00000020 and a name like SERVICE_WILL_NOT_STAY_UP. This page is the reference the crash screen links to.

Who raises one#

At a glance#

Codes MSL raises about itself#

Each of these is a condition MSL cannot continue past, detected where it actually happens. They are not the same as the errors that get a sentence and a retry — an instance that will not start, a disk that needs checking — because those leave MSL working. These do not.

0x00000010 · SERVICE_CANNOT_LISTEN#

Subsystem: mslhd — the control socket. Raised by: mslhd, about itself.

MSL's background service could not open the socket everything else talks to it on, so nothing can reach it: not the app, not msl, not a Linux app asking for a file. There is no degraded mode to fall back to, so it stops rather than running as something nothing can reach.

What to do. Another copy of it may already be running. Quit MSL, open it again, and if that does not help, restart the Mac.

0x00000011 · SIGNING_KEY_UNREADABLE#

Subsystem: instance identity — the machine key. Raised by: mslhd, about itself.

The key MSL signs your instances with is there and cannot be read.

What to do. Check that /Users/Shared/MSL and the machine-key file inside it still belong to you and are readable.

0x00000012 · KEY_STORE_UNPROTECTED#

Subsystem: MSL Admin Portal — the key store. Raised by: mslhd, about itself.

This Mac is managed, but the folder holding the administrator's keys can be written by other accounts — so signed policies no longer verify and the administrator's rules have silently stopped applying.

What to do. An administrator can repair it:

sudo chown -R root /Users/Shared/MSL && sudo chmod -R go-w /Users/Shared/MSL

0x00000013 · VIRTUALIZATION_REFUSED#

Subsystem: mslhd — the virtualization entitlement. Raised by: mslhd, about itself.

macOS will not let this copy of MSL's service create a virtual machine, so no instance can ever start. Almost always a copy of mslhd that was moved into place by hand instead of installed.

What to do. Install MSL from its package rather than copying the files in: the permission is part of the signature and does not survive a plain copy.

Codes MSL's observer raises#

These come from mslod, a small program that watches MSL from outside and is not part of it. Every threshold below is in minutes, not seconds: a crash screen for a healthy MSL is worse than no observer at all, so a single crash the service recovered from, an update replacing it, a kickstart, a slow reply while a guest's memory is written out, and the Mac waking from sleep are all recorded and never shown.

0x00000020 · SERVICE_WILL_NOT_STAY_UP#

Subsystem: mslhd — MSL's background service. Raised by: mslod.

MSL's background service has crashed and restarted several times in a few minutes, and never managed to answer anything in between. Nothing that needs it can work: not your instances, not the app, not the command line.

Detected as: four restarts of mslhd within five minutes, none of which replied to a request. One restart is launchd doing its job and is not this; restarts that did serve in between are a service being bounced, which is what an update does to it.

What to do. Quit MSL, then open it again — that reinstalls the service from the app. If it keeps happening, the crash report named mslhd in Console ▸ Crash Reports says why. The report panel on the crash screen already quotes the exception type it found there.

0x00000021 · SERVICE_STOPPED_ANSWERING#

Subsystem: mslhd — the control socket. Raised by: mslod.

The service is running and accepting connections, but it has stopped replying to them. Anything that asks it something now waits forever instead of being told no.

Detected as: five unbroken minutes with no reply and nothing written to MSL's own log by the service. Measured on a reply, never on a connection: a Unix socket's listen backlog is serviced by the kernel, so connecting succeeds against a service whose accept loop has wedged and proves nothing at all. The log is the second half of it — answering a status question waits on the same queue that freezes a guest and writes its memory to disk, so a shutdown saving several instances can legitimately leave the socket silent for minutes while the service is plainly still working.

What to do. Restart the service. Your instances keep their disks, and anything that was running comes back:

launchctl kickstart -k gui/$(id -u)/com.msl.mslhd

If it wedges again, restart the Mac before using MSL for anything you care about.

0x00000022 · SERVICE_IS_NOT_INSTALLED#

Subsystem: the installed programs in ~/Library/Application Support/MSL/bin. Raised by: mslod.

The program MSL runs everything through is missing from where MSL installs it, or is not executable, so nothing can start. An install or an update most likely stopped part-way.

Detected as: three unbroken minutes missing. An update replaces that file in milliseconds and the installer stops the service on purpose, so neither of those reaches this.

What to do. Open MSL once: the app reinstalls its own command-line programs every time it launches. If MSL will not open either, install it again from its package — your instances and their disks are untouched by that.

0x00000023 · STATE_DIRECTORY_UNUSABLE#

Subsystem: ~/Library/Application Support/MSL — instances, accounts and settings. Raised by: mslod.

MSL cannot use the folder it keeps your instances, accounts and settings in. Instances may appear to have vanished.

Detected as: two unbroken minutes in which the folder could not be written, or the file listing the instances could not be read. Tested by actually writing, because the permission bits lie on a read-only volume.

What to do. Check that ~/Library/Application Support/MSL still belongs to you and is readable and writable, and that the disk it is on is not full.

Codes nothing understands#

A signal, or an error nothing caught. These carry no advice and name no subsystem, deliberately: inventing a next step for something MSL cannot explain, or blaming a part of MSL nobody has established was at fault, would both be worse than admitting it.

An uncaught error shows as UNCAUGHT_ and the error's own name instead of a number.

What MSL does not trade away#

macOS writes its own crash report, with a backtrace, and that file is the only thing that ever makes a crash like this fixable. So MSL shows the screen and then lets the process die exactly as it would have. Nothing is given up for the window.

You will find that report in Console ▸ Crash Reports, named after the part that stopped — mslhd, MSLApp, MSLFiles, msl or mslod.