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:
- boot.log - boot information
- cron - cron logs
- cups - directory of all printing logs
- httpd - Apache logs
- mail - Mail server logs
- maillog - The mail log
- messages - Post-boot kernel information
- 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.
Advertisement
someone has deleted the folder from sharing folder, how i know the IP address of system who has deleted folder.
its SUSE linux 10.2
please help me.
Nothing personal to the author because I did get benefit, but it doesn’t really cover log files extensively enough. I would like to know what the messages mean in greater detail. I run Ubuntu and on Ubuntu there is a program to view all these files so viewing them isn’t a problem. Cracking the log file code is another problem.
Thanks for the article please elaborate on this subject.
@Eric D
less +F logfile.log
Thanks, Jack. The log files is one aspect of the computer that I always knew that I need to understand better, but just never got around to it. You have once again proven that you know what we really need, and write great articles about them instead of simply rehashing what is being blogged about everywhere else. Thanks!
Don’t use “tail -f”, use “less” and then type “F”.
– If you see that there were 150 lines of errors at the end of your log, you need to stop, open with less… If you’re in less already, just hit ctrl-c and go up.
– You open a console to check a log file, realise it’s showing large lines, extend the window size. With tail, the already printed logs will remain cut, only the new lines will print to the new full width. With less, it redisplays your screen accordingly
– With less, you can pause your “tail” to look at a specific line and resume later.
The only drawback with this method is that you need to type “F” inside less, AFAIK there is no command-line flag like “less -f blah.log”.
It goes without saying that the emdashes in the above comment are supposed to be double dashes. I have no idea why someone would feel the need to write code that tells me what I meant to type.
This might work a bit better for those with long uptimes where logfile rotation is an issue.
tail –follow=name –retry –max-unchanged-stats=5 /var/log/foo