One of the most common tools you probably use for problem analysis is the Windows Event Logger. It can be a pretty useful graphical tool, but the Linux world was built around the command-line so it instead gets the text-based dmesg.

dmesg displays the last set of system messages. If you run this shortly after a reboot, it will display kernel boot messages. In it you will see extreme levels of detail about various devices, drivers, and other kernel-level initializations. This can be fairly verbose, more so than even the messages you see when you boot Windows in debug mode. The information in each is functionally the same. They are designed to show you what the kernel is doing.

In Linux, dmesg provides a glimpse into a 16KB slice of kernel memory reserved for such messages. When that space has been filled up with messages, the log loops and new messages are written to the beginning which overwrites earlier messages. This is important because while dmesg shows you everything in chronological order, if your system has been up for a while the boot messages may have been lost.

To assist with this looping situation, Linux also has the syslog. Syslog is a Linux service that begins its life early in the boot process, and its role is to funnel messages into long-term storage from other services or applications. Invariably, these files are found somewhere in /var, a common Linux directory tree used to store "variable" data. Lots of things live in /var, like the system logs in /var/log, crash dumps, web server access logs, database caches, lock files, process ID (PID) files, Linux's scheduled tasks called crontabs, and others.

System logs contain sensitive data, as they provide a detailed insight into the system. So you may find that many directories in /var are protected such that only the user syslog or root has access to read or write. For those that you can see, they'll typically have a format similar to the following:

• Dec 14 17:00:00 server1 newsyslog[62807]: logfile turned over due to size>100K

Specifically we see: a timestamp (which often does not include the year), the hostname, the service the message is for (with the PID in brackets), and the message itself. If you ever find yourself building or supporting Linux servers, you'll be looking at these files quite a bit, probably about as often as you check out your Event Log in Windows.
That's it for dmesg and system logs. Since we're on the subject of boot messages, next time I'll cover the init command, which boots the system.