Why `journalctl -k` usage preference could be better over `dmesg` while listing kernel events

Dedicated for dmesg users.

By seeing a massive dmesg usage everywhere, we should everybody to recall what the dmesg is:

$ man dmesg | head -n4 | tail -n1
       dmesg - print or control the kernel ring buffer

so dmesg prints a buffer's content. A buffer which uses is a limited amount of memory. At some overflow it cuts an older events off from it. So after some duration of kernel run you could see only recent msgs there, not all which was earlier.

If you want a full kernel log output from the last boot up we suggest to use

sync;
journalctl -k -o short-monotonic --no-host --no-pager

or

sudo journalctl --sync;
journalctl --dmesg --output=short-monotonic --no-host --no-pager

One of a real machine examples:

$ sudo dmesg | tail -n1 | cut -c1-70
[10757.784033] audit: type=1105 audit(1634914575.371:205): pid=30152 u
$

while a head lines is not attached at the initial boot up event anymore.

$ sudo dmesg | head -n1 | cut -c1-70
[   60.593968] audit: type=1131 audit(1634903878.177:105): pid=1 uid=0
$

So for that current boot a 3 hours of time was enough to made dmesg to forget an earlier kernel messages which was since a machine boot up.
It prints an in-RAM buffer content, but any buffer has it’s size/capacity - a memory limit of stored data in it.


One more benefit:
dmesg as being in-RAM info presenter unable to show info from previous PC boot ups, while the systemd journal called with -bX argument can, where X is boot up index (which could be found by journalctl --list-boots).

1 Like

Everybody got an invite to edit that post above: it is a wiki post.
Please improve the info to make it to be as much closer to nowadays reality as we can.
Welcome to :building_construction: it together!