[GTALUG] war story: read you kernel log (dmesg) once in a while

[Daniel Wayne Armstrong]

On 2021-03-19 11:24, D. Hugh Redelmeier via talk wrote:
> [One reason for this message is to test if the mailing list is working. 
>  I
> haven't seen a new message in a 10 days.]
> 
> dmseg command
> =============
> 
> The dmesg command shows you the kernel log.  It takes the log from the
> kernel itself.  It is stored in a circular RAM buffer, so you can still
> read it if the normal logging system isn't working.  This buffer is a
> fixed size so older messages can get pushed out by newer ones if there 
> is
> enough logging going on.
> 
> You can get more info on Fedora by
> 	journalctl -b
> but it isn't limited to kernel messages.  It does colour-code messages
> based on severity, so that's a nice plus.  Since this log typically 
> goes
> to disk, it tends to be complete.  Oh: the -b flag means: start from 
> the
> most recent boot -- logs can go back months and years.
> 
> As an old timer, my first instinct is to use dmesg.
> 
> looking at kernel messages
> ==========================
> 
> dmesg | less -i
> 
> dmesg pours out a lot of lines.  less is a good way of navigating this
> log.  The -i makes searches within less case-insensitive.

A good read. Thanks for sharing!

Small note: On Debian (and other distros?) if a non-root user runs dmesg 
to read the contents of the kernel message buffer they will see ...

dmesg: read kernel buffer failed: Operation not permitted

Turns out it is a security feature - 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=842226#15

To allow users to read the kernel log without being prompted for a 
password, modify /etc/sysctl.conf by adding ...

kernel.dmesg_restrict = 0

... and reload the configuration ...

$ sudo sysctl -p