After starting up my machine in verbose mode (cmd + v at start-up) I want to view the generated log messages, to debug an error I'm receiving (the error). The error is only displayed on the screen briefly during startup, before the machine reboots. As a result, there's no time to read it properly.

Does OS X provide a separate log file for start-up messages, or are these buried within the kernel.log and system.log files? If they are buried within these files, is there a quick way to jump to the point where the system boots, within the console viewer?


5 Answers 5


Starting in at least Snow Leopard and possibly Leopard, all logging on the system goes through the Apple System Log (ASL) mechanism, which is like a central daemon and database for all log messages. The ASL daemon also makes sure that appropriate log messages that meet certain traditional criteria are written out to traditional flat text log files like system.log and kernel.log, but everything goes to the ASL database as well.

For more information, see the man pages for syslog(1), logger(1), syslog(3), asl(3), syslog.conf(5), asl.conf(5), syslogd(8), etc.

You can use syslog(1) to issue queries against the ASL database. Also, /Utilities/Console.app provides a GUI for generating and saving custom queries for the ASL database.

I'm pretty sure that the kernel's message buffer (traditionally viewed with dmesg(8)) gets dumped into the ASL database as soon as boot has proceeded far enough for syslogd to be running, so you shouldn't need to call dmesg directly, except through force of habit. Or if your system isn't booting far enough for syslogd to be running.

  • Does this work for previous boots? The problem I was experiencing when I wrote this question (resolved now, thankfully) was only occurring intermittently. So say, every other boot, it was Kernel panic on me, and what I wanted to do was on the next successful boot, review the log file, find the previous boot, and try and debug. Mar 28, 2012 at 16:08
  • @purpletonic Yes, everything that gets sent to ASL gets put in a database, where it stays for a default of 7 days (this can be adjusted with asl.conf(5)). So if you were debugging booting problems and rebooted several times the same day, they'd be there by default. And if it was a longer-term problem, you could adjust ASL's retention period to keep stuff longer.
    – Spiff
    Mar 28, 2012 at 16:57
  • 2
    This answer does not actually say how I get to see the output from the "verbose" boot process, though. Once booted, dmesg does only show some recent entries but not the boot log. Trying this on 10.12.6 - there's no "kernel.log" file any more, either. Oct 28, 2018 at 12:50

The accepted answer (by Spiff) was not helpful to me, nor is there a kernel.log any more.

What works for me (on macOS 10.12.6) is this command:

log show --predicate "processID == 0" --start $(date "+%Y-%m-%d") --debug

It shows all of today's kernel msgs, including the boot process. It needs some cleaning up, but at least it contains all I needed to find.

  • 3
    This works for me too. Thank you. The other answers show things not necessarily related to boot up, or don't show EXACTLY what's being printed during boot. Your answer does +1. And it's color coded too!
    – Max Coplan
    Sep 27, 2019 at 17:32
  • This is exactly what I needed for debugging a very slow Mac startup at my work. It's kernel level log data so it really is communicating nearly everything going wrong on the machine. Nov 29, 2022 at 13:54

Open Terminal.app and run

sudo dmesg

(you'll be asked for your password)

This will display system messages from the last startup until now (you'll find the startup messages at the top of the output). You may try

sudo dmesg | more

this will output those messages page by page.

  • Nice! I'd use less instead of more, it's far more convenient and doesn't clutter your terminal scrollback.
    – SilverWolf
    Oct 19, 2018 at 0:46

I myself wondering how to get the log most appropriate to the startup without access to the console/terminal. It crashed at startup but you can get access to the file system through the install disk (I had a dual linux boot available). The file is:


If you can access the console within the operating system, it's better to follow the other suggestions and use the appropriate commands.


I know this is pretty stupid, but nonetheless sometimes this was the fastest, or even the only option for me:

Use your smartphone or any other camera to film the screen and watch the video later. If it's happening really really fast you can even play with slomo mode, if your camera has that option.

Again, I know this is the most ridiculous approach, but maybe someone is as helpless as me :D

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .