Learning Linux: Log Files - gHacks Tech News

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.

We need your help

Advertising revenue is falling fast across the Internet, and independently-run sites like Ghacks are hit hardest by it. The advertising model in its current form is coming to an end, and we have to find other ways to continue operating this site.

We are committed to keeping our content free and independent, which means no paywalls, no sponsored posts, no annoying ad formats or subscription fees.

If you like our content, and would like to help, please consider making a contribution:

Comments

  1. The Mighty Buzzard said on February 16, 2009 at 5:07 pm
    Reply

    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

  2. The Mighty Buzzard said on February 16, 2009 at 5:15 pm
    Reply

    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.

  3. Eric D said on February 17, 2009 at 1:12 pm
    Reply

    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”.

  4. What is Linux? said on February 17, 2009 at 3:14 pm
    Reply

    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!

  5. dreur said on March 13, 2009 at 5:29 pm
    Reply

    @Eric D
    less +F logfile.log

  6. Goddard said on January 21, 2010 at 6:31 am
    Reply

    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.

  7. Anand Banda said on January 21, 2013 at 12:37 pm
    Reply

    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.

Leave a Reply

Check the box to consent to your data being stored in line with the guidelines set out in our privacy policy

Please note that your comment may not appear immediately after you post it.