Coolest thing I learned a while back is "dmesg -T" - Dmesg with timestamps ! Who knew :P

The timestamps output by dmesg -T are inaccurate - e.g. on virtual machines that are frequently snapshotted for backup. This is clearly stated in the manpage:

       -T, --ctime
              Print human-readable timestamps.

              Be aware that the timestamp could be inaccurate!  The time source used for the logs is not updated after system SUSPEND/RESUME.

The timestamps use linux' local_clock (which is per-cpu). It will also drift, even if you never suspend/resume.

The longer the uptime, the higher this discrepancy can be.

This means the timestamp is useless for many purposes.

You can check the current offset using:

    echo test >> /dev/kmsg && uptime=$(cut -d' ' -f 1 /proc/uptime ) && timestamp=$(dmesg |tail -1| awk -F '[][]' {'print $2'}) && echo "$timestamp-$uptime" | bc

`dmesg -H` is one I use most often, it enables viewing output in a pager. `-w` is also useful, it 'follows' the output (doesn't return and prints more output as it is received)

Some people put up websites with dmesg output on them.

http://www.dimlight.org/number9/dmesg_index.html

That altix machine is crazy.

Isn't `dmesg` just `journalctl -k` on operating systems with systemd enabled?

It's more like the opposite. journalctl -k displays the kernel messages, but with a considerable amount of extra overhead because it has to go though the journal daemon.

https://github.com/systemd/systemd/blob/9afd5740391980fee5d8... https://github.com/systemd/systemd/blob/9afd5740391980fee5d8...

Whereas dmesg reads the kernel messages directly from the kernel.

https://github.com/karelzak/util-linux/blob/99c92a4820569970...

Not disputing your point, but some of that extra code does allow you to do cool things. Add a `-k -b=-{n}` to see a previous boot's dmesg, or filtering with `-k --until` for time filtering, &c. All with the same interface you're using to process your other logs too.