Getting Started With Linux – What Is dmesg?

25th May, 2016 by
Servers generally log a great deal of information about what they are doing, what applications are running and other system management activities. One set of logging in particular is performed by dmesg, or driver messages. If you’ve ever watched a Linux system boot up without a splash screen and wondered what all the text that scrolled up the screen too fast to see was, those were the messages that were logged to dmes

dmesg Log: Accessing Information for Debugging

This log is cleared each time the system boots and contains information from the Kernel’s message buffer, mostly related to the various hardware devices and drivers. This means that it can be very helpful when debugging hardware problems and setting up devices.

The dmesg information can be accessed using the dmesg command, or alternatively, the information is logged to the /var/log/kern.log logfile. It’s worth starting with a note on the format of the information logged in dmesg. It is as follows:

[ time ] device: message

The time is recorded as the number of seconds that have passed since the system started. The device is the name of the device/driver that provided the message. Finally, the message itself. When the message is logged to the kern.log file, it is prefixed with more helpful date and time than it was logged as, which makes tracing more historic events easier. As I mentioned earlier, dmesg itself is cleared each time the system boots so the contents will start with information about the boot parameters used when starting the system. To view the start of the dmesg output, you’ll need to pipe the output from the dmesg command through the head command as below:

dmesg | head

Similarly, to see the most recent message you can pipe the output through the tail command:

dmesg | tail

The contents of dmesg can get quite long, so it’s a good idea – if you want to read through it all – to pipe it through a paging output such as the less command:

dmesg | less

Note that there is a fixed length to the amount of information that can be stored in dmesg. As such, if a lot of messages are logged, older messages will disappear from the dmesg log. This is much more prominent on devices such as laptops than on servers, where the wifi network card may create a huge amount of messages that dmesg will handle.

Due to the huge number of messages that may be logged to dmesg, it’s more normal to be piping the output through the grep command in order to get information relevant to what you may be after. For example:

dmesg | grep CPU

dmesg | grep eth

dmesg | grep usb

With the first command we are looking for CPU information and with the second set of information about ethernet devices. The last command searches for information related to USB devices.

Looking through dmesg’s output, it’s easy to see there’s a lot of information that’s not particularly helpful without some knowledge of how the Linux Kernel works to get an understanding of what the output really means. Where it does help is with recording things like network port connection/disconnection events, port speeds, and link information. Similarly, information about USB device connection, links and types are all recorded, which can help when looking to debug issues with USB devices that are being attached to the computer. Disk errors will be logged in dmesg, making it somewhere to look for information if you suspect a disk in your server may be failing.

As logs go, dmesg is something that is rarely looked at under normal circumstances, but when needed can be incredibly useful and well worth knowing about. So have a little look through the messages on your server and get a feel for the information logged and situations in which it could be helpful in the future.