/proc/kmsg is a pseudo-file that contains the raw kernel messages, same output as dmesg -rThat file not showing anythingSome good answers on SO https://unix.stackexchange.com/question ... it-changes
e.g.Code:
sudo cat /proc/kmsgCode:
pi@pinas:/proc $ ls -ltr | grep kmsg-r-------- 1 root root 0 Jul 17 10:03 kmsgpi@pinas:/proc $ sudo cat /proc/kmsg^Cpi@pinas:/proc $ ls -ltr | grep kmsg-r-------- 1 root root 0 Jul 17 10:03 kmsg
I seems that it has a non-expected flie-pointer behavior (at least for me, just 2 of my computers). 1st time you do sudo cat /proc/kmsg it shows indeed raw kernel message buffer, but subsequent read efforts no output. A (circular) buffer is not a filesystem so maybe not so surprising. It is more like a stream/pipe.
Modern latest (rolling release) distros might not have any 'flat text' logfiles in /var/log anymore. Instead default is a comprehensive journal, is binary format. I use Grafana and influxDB, but mainly for live time-series data that need 'downsampling' at some point in time later. I have also used telegraf and some RPi config (search internet) where you can see what the Pi does and did as it also uses influxDB. I disabled it as it won't help you debugging kernel crashes for example. 'dmesg' fetches the info from /dev/kmsg, and presents that to you. You should make an equivalent of dmesg (with the tools you mention) or maybe just feed the journal into those tools. Files in /var/log are not the latest, so I made a simple external cat/fetch of the serial console output and also stored that on an external computer. But they are good for stats/history of course. But then still ask yourself what does it solve? How many system tuning will you do based on graphs in Grafana that you could not have done with using some basic Linux/UNIX tooling every now and then.
Statistics: Posted by redvli — Sun Jul 27, 2025 7:04 am