107

dmesg is a command to read the contents from /var/log/dmesg. The nice thing compared to less /var/log/dmesg is that I can use the -T flag for human readable time output.

Now I would like to look at /var/log/dmesg.0, to see how my computer crashed. The file contains the logs from previous session. But I want to use the -T flag from the dmesg command. Or something equivalent.

Any idea how?

I would not mind a graphical tool, but the best would be a cli solution.

4 Answers 4

161

Although a bit late for the OP...

I use Fedora, but if your system uses journalctl then you can easily get the kernel messages (dmesg log) from prior shutdown/crash (in a dmesg -T format) through the following.

Options:

  • -k (dmesg)
  • -b < boot_number > (How many reboots ago 0, -1, -2, etc.)
  • -o short-precise (dmesg -T)
  • -p priority Filter by priority output (4 to filter out notice and info).

NOTE: there is also an -o short and -o short-iso which gives you the date only, and the date-time in iso format respectively.

Commands:

  • All boot cycles : journalctl -o short-precise -k -b all
  • Current boot : journalctl -o short-precise -k
  • Last boot : journalctl -o short-precise -k -b -1
  • Two boots prior : journalctl -o short-precise -k -b -2
  • And so on

Example Output:

Feb 18 21:41:26.917400 localhost.localdomain kernel: usb 2-4: USB disconnect, device number 12
Feb 18 21:41:26.917678 localhost.localdomain kernel: usb 2-4.1: USB disconnect, device number 13
Feb 18 21:41:27.246264 localhost.localdomain kernel: usb 2-4: new high-speed USB device number 22 using xhci_hcd
Feb 18 21:41:27.419395 localhost.localdomain kernel: usb 2-4: New USB device found, idVendor=05e3, idProduct=0610
Feb 18 21:41:27.419581 localhost.localdomain kernel: usb 2-4: New USB device strings: Mfr=1, Product=2, SerialNumber=0
Feb 18 21:41:27.419739 localhost.localdomain kernel: usb 2-4: Product: USB2.0 Hub
Feb 18 21:41:27.419903 localhost.localdomain kernel: usb 2-4: Manufacturer: GenesysLogic

The amount of boots you can look back on can be viewed with the following.

  • journalctl --list-boot

The output of journalctl --list-boot looks like the following.

-6 cc4333602fbd4bbabb0df2df9dd1f0d4 Sun 2016-11-13 08:32:58 JST—Thu 2016-11-17 07:53:59 JST
-5 85dc0d63e6a14b1b9a72424439f2bab4 Fri 2016-11-18 22:46:28 JST—Sat 2016-12-24 02:38:18 JST
-4 8abb8267e06b4c26a2466562f3422394 Sat 2016-12-24 08:10:28 JST—Sun 2017-02-12 12:31:20 JST
-3 a040f5e79a754b2a9055ac2598d430e8 Sun 2017-02-12 12:31:36 JST—Sat 2017-02-18 21:31:04 JST
-2 6c29e3b6f6a14f549f06749f9710e1f2 Sat 2017-02-18 21:31:15 JST—Sat 2017-02-18 22:36:08 JST
-1 42fd465eacd345f7b595069c7a5a14d0 Sat 2017-02-18 22:51:22 JST—Sat 2017-02-18 23:08:30 JST  
 0 26ea10b064ce4559808509dc7f162f07 Sat 2017-02-18 23:09:25 JST—Sun 2017-02-19 00:57:35 JST
6
  • 49
    Late for the OP. Never late for future googlers!
    – Qian
    Commented Jun 30, 2019 at 10:07
  • 2
    journalctl -k -b all shows all dmesgs available
    – Sérgio
    Commented Jan 1, 2021 at 13:43
  • @Sérgio Thanks updated! seems what I had previously showed messages other than from the kernel buffer as well. Commented Jan 4, 2021 at 10:02
  • 1
    I've been googling how to get something like journalctl's --since for dmesg. So here I am, thank you!
    – msa
    Commented May 30, 2021 at 7:20
  • 1
    Nice! I have been getting plenty of notifications for this but somehow missed that there was a new reply :)
    – donquixote
    Commented Oct 26, 2021 at 13:32
55

To clear up a fundamental misconception, dmesg does not read from /var/log/dmesg. It reads directly from the kernel ring buffer and gives you the most recent N messages. Towards the end of the boot process, dmesg is invoked to write the boot messages to /var/log/dmesg (with older versions of that file being rotated in the usual manner).

Once you have a syslog running (syslogd, rsyslogd, syslog-ng, etc.) it reads from the kernel buffer and writes to a file such as /var/log/kern.log. (This is for Debian; other systems will vary). Assuming your system was able to write to disk and flush the disk buffers before it crashed, that is where you will find the dying screams of the kernel.

On my Debian system the /var/log/kern.log file contains human-readable timestamps.

5
  • 1
    I think this answers my question, thanks! Unfortunately I still cannot figure out why it crashes on suspend, but that's another story.
    – donquixote
    Commented Jan 26, 2015 at 13:51
  • One my machine things other than dmesg get written to kern.log, specifically the following daemons specifically the following daemons gnome-keyring-d,goa-daemon,gvfsd,gvfsd-network,gvfs-gphoto2-vo,NetworkManager,upowerd
    – Att Righ
    Commented Mar 30, 2017 at 16:07
  • @AttRigh the only thing supposed to write to that file is the kernel. You might like to ask a new question Commented Mar 30, 2017 at 21:02
  • @roima Interesting... I don't really have a question to ask since I'm happy using journalctl to get the logs! I just thought others might be interested in this inconsistency. Looking at my system i) it's using rsyslog to log to kern.log using the following entry kern.* -/var/log/kern.log, a call to debsums -e confirms that none of my configuration files related to rsyslog or systemd has been modified (serverfault.com/questions/90400/…), my version of rsyslog is 8.24.0-1, and I'm using debian stretch.
    – Att Righ
    Commented Mar 31, 2017 at 12:16
  • @AttRigh you might also like to read unix.stackexchange.com/a/294206/100397 Commented Mar 31, 2017 at 12:32
13

In Debian, dmesg logs are stored as:

  • /var/log/dmesg (live and uncompressed)
  • /var/log/dmesg.0 (last session and uncompressed)
  • /var/log/dmesg.1.gz (penultimate and compressed)
  • /var/log/dmesg.2.gz (antepenultimate and compressed)
  • /var/log/dmesg.3.gz (4th from last and compressed)
  • /var/log/dmesg.4.gz (5th from last and compressed)

If you have the appropriate permissions, you can read them with cat, more or less for plain ones and zcat, zmore or zless for compressed ones

3
  • This is not the case on my debian (testing - stretch, not particularly modified, up-to-date as of today). This may be related to systemd, since dmesg is logged to systemd (see answer below).
    – Att Righ
    Commented Mar 30, 2017 at 16:10
  • 11
    thanks for your answer. Now I am cognizanted of the English words penultimate and antepenultimate
    – Sang
    Commented Dec 2, 2019 at 3:55
  • 2
    Upvoted for using "antepenultimate" (also a good answer)
    – kmarsh
    Commented Mar 10, 2020 at 13:10
0

For alpinelinux,

echo 'previous_dmesg=yes' >> /etc/conf.d/bootmisc

will do mv /var/log/dmesg /var/log/dmesg.old in bootmisc.

You must log in to answer this question.

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