Welcome to Linux Knowledge Base and Tutorial
"The place where you learn linux"

 Create an AccountHome | Submit News | Your Account  

Tutorial Menu
Linux Tutorial Home
Table of Contents
Up to --> Solving Problems

· Solving Problems Yourself
· Preparing Yourself
· Checking the Sanity of Your System
· Problem Solving
· Crash Recovery
· Hardware Diagnostic Tools
· Netiquette

Glossary
MoreInfo
Man Pages
Linux Topics
Test Your Knowledge

Site Menu
Site Map
FAQ
Copyright Info
Terms of Use
Privacy Info
Disclaimer
WorkBoard
Thanks
Donations
Advertising
Masthead / Impressum
Your Account

Communication
Feedback
Forums
Private Messages
Recommend Us
Surveys

Features
HOWTOs
News
News Archive
Submit News
Topics
User Articles
Web Links

Google
Google


The Web
linux-tutorial.info

Who's Online
There are currently, 168 guest(s) and 1 member(s) that are online.

You are an Anonymous user. You can register for free by clicking here

  
Linux Tutorial - Solving Problems - Solving Problems Yourself - Checking the Sanity of Your System
  Preparing Yourself ---- Problem Solving  


Checking the Sanity of Your System

Have you ever tried to do something and it didn't behave the way you expected it to? You read the manual and typed in the example character for a character only to find it didn't work right. Your first assumption is that the manual is wrong, but rather than reporting a bug, you try the command on another machine and to your amazement, it behaves exactly as you expect. The only logical reason is that your machine has gone insane.

Well, at least that's the attitude I have had on numerous occasions. Although this personification of the system helps relieve stress sometimes, it does little to get to the heart of the problem.If you want, you could check every single file on your system (or at least those related to your problem) and ensure that permissions are correct, the size is right, and that all the support files are there. Although this works in many cases, often figuring out which programs and files are involved is not easy.

Fortunately, help is on the way. Linux provides several useful tools with which you can not only check the sanity of your system but return it to normal. I've already talked about the first set of tools. These are the monitoring tools such as ps and vmstat. Although these programs cannot correct your problems, they can indicate where problems lie.

If the problem is the result of a corrupt file (either the contents are corrupt or the permissions are wrong), the system monitoring tools cannot help much. However, several tools specifically address different aspects of your system.

Linux provides a utility to compute a checksum on a file, called sum. It provides three ways of determining the sum. The first is with no options at all, which reports a 16-bit sum. The next way uses the -r option, which again provides a 16-bit checksum but uses an older method to compute the sum. In my opinion, this method is more reliable because the byte order is important as well. Without the -r, a file containing the word "housecat" would have the same checksum if you changed that single word to "cathouse." Although both words have the exact same bytes, they are in a different order and give a different meaning. Note that I have seen that newer versions of sum default to the -r behavior. If you want the older behavior (and get the same checksum in this example), use the -s option.

On many systems, there is the md5sum command. Instead of creating a 16-bit sum, md5sum creates a 128-bit sum. This makes it substantially more difficult to hide the fact that a file has changed.

Because of the importance of the file's checksum, I created a shell script while I was in tech support that would run on a freshly installed system. As it ran, it would store in a database all the information provided in the permissions lists, plus the size of the file (from an ls -l listing), the type of file (using the file command), and the checksum (using sum with the -r option). If I was on the phone with a customer and things didn't appear right, I could do a quick grep of that file name and get the necessary information. If they didn't match, I knew something was out of whack.

Unfortunately for the customer, much of the information that my script and database provided was something to which they didn't have access. Now, each system administrator could write a similar script and call up that information. However, most administrators do not consider this issue until it's too late.

We now get to the "sanity checker" with which perhaps most people are familiar: fsck, the file system checker. Anyone who has lived through a system crash or had the system shut down improperly has seen fsck. One unfamiliar aspect of fsck is the fact that it is actually several programs, one for each of the different file systems. This is done because of the complexities of analyzing and correcting problems on each file system. As a result of these complexities, very little of the code can be shared. What can be shared is found within the fsck program.

When it runs, fsck determines what type of file system you want to check and runs the appropriate command. For example, if you were checking an ext2fs file system, the program that would do the actually checking would be fsck.ext2 (typically in the /sbin directory).

Another very useful sanity checker is the rpm package manager (assuming that your system uses the RPM file format) that is the RPM program itself. As I talked about earlier, the rpm program is used to install additional software. However, you can use many more options to test the integrity of your system.

When the system is installed, all of the file information is stored in several files located in /var/lib/rpm. These are hashed files that rpm can use but mean very little to us humans. Therefore, I am not going to go into more detail about these files.

Assuming you know what file is causing the problem, you can use rpm to determine the package to which this file belongs. The syntax would be

The -q puts rpm into query mode and the -f tells it to query the following file and tell me to what package it belongs. Once you know to what package a file belongs, you can verify the package. For example, lets say that you believe that there is something wrong with the xv file viewer. Its full path is /usr/bin/X11R6/xv, so to find out to what package it belongs, the command would be

This tells you that xv is part of the package

xv-3.10a-3

Now use the -V option to verify the package:

If rpm returns with no response, the package is fine. What if the owner and group are wrong? You would end up with an output that looks like this:

..UG. /usr/bin/X11R6/xv

Each dot represents a particular characteristic of the file. These characteristics are

5 MD5 checksum
S File size
L Symbolic link
T Modification time
D Device
U User
G Group
M Mode (permissions and file type)

If any of these characteristics are incorrect, rpm will display the appropriate letter.

If you wanted to check all of the packages you could create a script that looks like this:

The first rpm command simply lists all of the package and pipes it into the read, which then loops through each package and verifies it. Since each file will be listed, you should have some seperator between each packages.

 Previous Page
Preparing Yourself
  Back to Top
Table of Contents
Next Page 
Problem Solving


MoreInfo

Test Your Knowledge

User Comments:


You can only add comments if you are logged in.

Copyright 2002-2009 by James Mohr. Licensed under modified GNU Free Documentation License (Portions of this material originally published by Prentice Hall, Pearson Education, Inc). See here for details. All rights reserved.
  
Show your Support for the Linux Tutorial

Purchase one of the products from our new online shop. For each product you purchase, the Linux Tutorial gets a portion of the proceeds to help keep us going.


Login
Nickname

Password

Security Code
Security Code
Type Security Code


Don't have an account yet? You can create one. As a registered user you have some advantages like theme manager, comments configuration and post comments with your name.

Help if you can!


Amazon Wish List

Did You Know?
You can get all the latest Site and Linux news by checking out our news page.


Friends



Tell a Friend About Us

Bookmark and Share



Web site powered by PHP-Nuke

Is this information useful? At the very least you can help by spreading the word to your favorite newsgroups, mailing lists and forums.
All logos and trademarks in this site are property of their respective owner. The comments are property of their posters. Articles are the property of their respective owners. Unless otherwise stated in the body of the article, article content (C) 1994-2013 by James Mohr. All rights reserved. The stylized page/paper, as well as the terms "The Linux Tutorial", "The Linux Server Tutorial", "The Linux Knowledge Base and Tutorial" and "The place where you learn Linux" are service marks of James Mohr. All rights reserved.
The Linux Knowledge Base and Tutorial may contain links to sites on the Internet, which are owned and operated by third parties. The Linux Tutorial is not responsible for the content of any such third-party site. By viewing/utilizing this web site, you have agreed to our disclaimer, terms of use and privacy policy. Use of automated download software ("harvesters") such as wget, httrack, etc. causes the site to quickly exceed its bandwidth limitation and are therefore expressly prohibited. For more details on this, take a look here

PHP-Nuke Copyright © 2004 by Francisco Burzi. This is free software, and you may redistribute it under the GPL. PHP-Nuke comes with absolutely no warranty, for details, see the license.
Page Generation: 0.14 Seconds