Detecting kernel panics using Jamf Pro
Something that has (mostly) become more rare on the Mac platform are kernel panics, which are computer errors from which the operating system cannot safely recover without risking major data loss. Since a kernel panic means that the system has to halt or automatically reboot, this is a major inconvenience to the user of the computer.
Kernel panics are always the result of a software bug, either in Apple’s code or in the code of a third party’s kernel extension. Since they are always from bugs and they cause work interruptions, it’s a good idea to get on top of kernel panic issues as quickly as possible. To assist with this, a Jamf Pro Extension Attribute has been written to detect if a kernel panic has taken place. For more details, please see below the jump.
When a Mac has a kernel panic, the information from the panic is logged to a log file in /Library/Logs/DiagnosticReports. This log file will be named something similar to this:
Kernel-date-goes-here.panic
The Extension Attribute is based off an earlier example posted by Mike Morales on the Jamf Nation forums. It performs the following tasks:
- Checks to see if there are any logs in the /Library/Logs/DiagnosticReports with a .panic file extension.
- If there are, check to see which are from the past seven days.
- Output a count of how many .panic logs were generated in the past seven days.
To test the Extension Attribute, it is possible to force a kernel panic on a Mac. To do this, please use the process shown below:
1. Disable System Integrity Protection
2. Run the following command with root privileges:
dtrace -w -n "BEGIN{ panic();}"
3. After the kernel panic, run a Jamf Pro inventory update.
After the inventory update, it should show that at least one kernel panic had occurred on that Mac. For more information about kernel panics, please see the link below:
https://developer.apple.com/library/content/technotes/tn2004/tn2118.html
The Extension Attribute is available below and at the following address on GitHub:
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
#!/bin/bash | |
# Detects kernel panics which occurred in the last seven days. | |
# | |
# Original idea and script from here: | |
# https://www.jamf.com/jamf-nation/discussions/23976/kernal-panic-reporting#responseChild145035 | |
# | |
# This Jamf Pro Extension Attribute is designed to | |
# check the contents of /Library/Logs/DiagnosticReports | |
# and report on how many log files with the file suffix | |
# of ".panic" were created in the previous seven days. | |
PanicLogCount=$(/usr/bin/find /Library/Logs/DiagnosticReports -Btime -7 -name *.panic | grep . -c) | |
echo "<result>$PanicLogCount</result>" | |
exit 0 |
I have had my machine reboot this week and show the multi language prompt stating that there was an issue and it would continue to start after X seconds. I assumed that would be a kernel panic, but I have no .panic files in /Library/Logs/DiagnosticReports. Is that type of crash different and is it possible to track these?
I’ve observed that some kernel panics will have a log named “.content.panic”. The period in front of “content” will mark it as an invisible file, so it wouldn’t appear in the Finder.
This is in Terminal using sudo ls -al /Library/Logs/DiagnosticReports. Still no panic files. Very odd. Thanks for the response.
If you have a T2 Mac and the panic is being caused by the Bridge OS, the panic logs are written to /Library/Logs/DiagnosticReports/ProxiedDevice-Bridge/