Reading a crash report

MSL's crash screen is two halves that disagree on purpose. The picture is a joke, because there is nothing useful to say in the moment somebody's work disappears. The panel beside it is the opposite: a plain report, in the order you actually need it.

The panel is the part you quote. Copy report puts all of it on the clipboard.

The fields#

MSL's observer#

mslod is a small program that watches MSL from outside and does nothing else. It is installed beside MSL's other programs and runs as its own login job — never inside MSL's background service, because a watchdog that lives inside the thing it watches is missing at the only moment it matters.

Nothing in MSL depends on it. If it is not running, MSL works exactly the same; you simply get no report when something goes badly wrong. msl doctor says whether it is running.

What it watches#

From outside, every few seconds, using nothing but the process table and MSL's own control socket:

• the background service starting, stopping and being replaced, by process id;
• whether it answers, not merely whether it can be connected to;
• whether it is still writing its own log, which is how a service that is merely slow is told apart from one that has wedged;
• every Linux application host starting and ending, and which instance each belongs to;
• your instances appearing, running and stopping;
• crash reports macOS writes for any part of MSL, and the exception type inside them;
• whether MSL's own folder can be written and its list of instances read.

It also quotes MSL's own log lines into its record, so one file holds both what MSL said about itself and what was seen from outside. Guest kernel output is left out — that is Linux talking, not MSL.

When it interrupts you#

Almost never, by design. All of the following are recorded and not shown:

• one crash that the service came back from — that is the system working;
• the service being replaced during an update, or stopped by the installer;
• launchctl kickstart;
• a slow reply while MSL freezes and writes out a guest's memory, however long it takes;
• the Mac waking from sleep;
• the service being off because you turned it off;
• MSL having already put up its own crash screen, which says more than the observer can.

Each stop code is shown once per session, and restarting the observer does not reset that. A crash screen that reappears every few minutes is its own bug, and it buries whatever you were doing about the first one.

Its record#

~/Library/Logs/MSL/observer.log, and it belongs to this time you turned the Mac on. The next boot deletes it and starts again, so there is nothing to clear out and nothing that grows forever. Restarting the observer, or MSL, does not clear it — only booting does.

That is deliberately short-lived, so an incident keeps its own copy. When the observer raises a stop code it writes observer-incident.txt into ~/Library/Application Support/MSL with the code, what it measured, and the tail of what it saw beforehand. Copy report includes all of it. That file survives the log, and is removed once the screen has shown it.

Turning it off#

It follows Start MSL's background service in MSL's settings. Turning that off removes the observer's job along with the service's; turning it back on reinstates both.