27

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.

25

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.

  • 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 Jan 26 '15 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 Mar 30 '17 at 16:07
  • @AttRigh the only thing supposed to write to that file is the kernel. You might like to ask a new question – roaima Mar 30 '17 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 Mar 31 '17 at 12:16
  • @AttRigh you might also like to read unix.stackexchange.com/a/294206/100397 – roaima Mar 31 '17 at 12:32
31

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:

  • 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
  • 1
    Late for the OP. Never late for future googlers! – Qian Jun 30 at 10:07
3

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 (3rd from last and compressed)
  • /var/log/dmesg.4.gz (4th from last and compressed)

Iif you have permits, you can read them with cat, more or less for plain ones and zcat, zmore or zless for compressed ones

  • 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 Mar 30 '17 at 16:10

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.