[Osiris]

Learning Linux: Log Files

If you are serious about learning Linux then one aspect you will want to familiarize yourself with is log files. This concept will help you to understand why when you go to a mailing list with a problem and, when someone asks you the contents of a particular log file, you are able to offer enough information to help solve your problem. Log files are very good for helping you deduce what is going wrong with a system. There are, however, a lot of log files to wade through. That’s where I come in. In this article I am going to show you the first places to look when you have problems with a Linux system. I won’t cover all of the log files (at least yet), but I will get you started on what will hopefully become a long history of too much information.
dmesg
When I have a problem (or when I am attaching a usb device) one of the first places I go is the dmesg command. The dmesg command prints out the kernel keyring buffer. The information you will get will be all of the information you do not see when your system is booting. This is a great place to get information (low level) on your hardware. On one of my laptops, I run dmesg and near the top I see:
Phoenix BIOS detected: BIOS may corrupt low RAM, working it around.
last_pfn = 0x7f6d0 max_arch_pfn = 0x100000
x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106
kernel direct mapping tables up to 38000000 @ 10000-15000
Using x86 segment limits to approximate NX protection
RAMDISK: 37c6a000 - 37fef4a2

From that I can tell I have a Phoenix bios. Pretty obvious. A little later I see:
Security Framework initialized
SELinux: Initializing.
SELinux: Starting in permissive mode
Now I know Security Enhanced Linux is starting, in permissive mode, at bootup. And even further on down the line I see:
CPU1: Intel(R) Pentium(R) Dual CPU T2390 @ 1.86GHz stepping 0d
checking TSC synchronization [CPU#0 -> CPU#1]: passed.
Brought up 2 CPUs
Total of 2 processors activated (7447.76 BogoMIPS)
The above shows me information about my CPU. Good to know.
The most important information you will probably get from dmesg is the information regarding attached USB devices. When you plug in a USB device you will need to know what special device this is attached to so you can mount it. This will occur at the bottom of the dmesg command output.
The output of dmesg is quite long and will scroll by very quickly. When I run this command I always pipe it through the less command like so:
dmesg | less
This way I can view the output one page at a time.
/var/log
This special directory is the Mac Daddy of information gathering. Fire up a terminal window and issue the command ls /var/log/ and see what it contains. You see, included in this listing, such log files and log directories as:

• <LI itxtvisited="1">boot.log - boot information <LI itxtvisited="1">cron - cron logs <LI itxtvisited="1">cups - directory of all printing logs <LI itxtvisited="1">httpd - Apache logs <LI itxtvisited="1">mail - Mail server logs <LI itxtvisited="1">maillog - The mail log <LI itxtvisited="1">messages - Post-boot kernel information <LI itxtvisited="1">secure - Security log
• Xorg.0.log - X Server log

You can see the listing of log files in the /var/log directory, but in order to actually read the log files you have to be the root user (or use sudo).
Viewing with tail
One of the handiest methods of viewing log files is using the tail command. What tail does is follow the running output of a log file. For instance if I want to follow my /var/log/secure log to watch for security issues I would enter the command tail -f /var/log/secure. The f switch tells tail to follow. If you don’t add the f switch tail will just list the output all at once (as if you just issued less /var/log/secure.)
Final Thougths
There is so much information to be gained from reading log files. The Linux operating system makes reading log files easy, once you know which log file does what. Take a poke around /var/log to find out exactly what you have and where you need to look for the problem you are having.