BadgerFiles

Effective problem solving in Linux has nothing to do with knowing what the right answer is; it’s about asking the right questions to find the right answers. You can efficiently solve problems and enhance your Linux experience by using a series of five questions to resolve configuration issues and error messages.

The individual questions that follow seem simple, but taken together they provide a powerful method for solving problems and learning Linux. I had a chance to ask Jeremy Garcia, the founder of LinuxQuestions.org, his perspective on problem solving and asking questions from the eye of a beginning Linux user. LinuxQuestions.org has been a growing piece of the Linux support community for the past four years and is a place where both novices and experienced users can ask questions and/or provide answers.

What Tools Are Needed?

The thought of typing Linux commands can be daunting to a fledgling Linux user. Nevertheless, knowledge of some basic commands is essential, and you should know how to move around your system from a command line. Whether you find help in a forum, a document, or from a vendor, you’ll encounter instructions from a command-line perspective. The tendency to provide support from a command line is not a way for experienced users to show how much they know. Rather, a command line offers control and consistency.

You learn commands by using them. Start with the basics: ls to list files in a directory, cd to change directories, mv to move or rename files or directories, cp to copy files or directories, more to read a file on the screen, and nano or vi to edit a file. If you want to know which options you can pass to a command, append -help to the command or view the man page. For example, mv -help or man mv will show the description, usage, and available options for the mv command. The Linux Wiki at www.linuxquestions.org offers a more complete list of Linux commands.

Asking yourself which tools are needed does not stop once you master some basic Linux commands. As you grow in knowledge and experience, so too will your repertoire of tools. You may only know which tool is needed after the following questions are answered.

What Information Is Needed?

LinuxQuestions.org’s founder, Jeremy Garcia, answers this question with, “In general, the more information the better.” Specific items on his list include the Linux distribution, the kernel version, the exact error messages or symptoms, and the steps to reproduce the problem.

You are expected to know which Linux distribution you are using. To not know is like not knowing if you drive a Ford or a Dodge. Finding the kernel version is not so obvious. The command uname - a will report the kernel information. This is an information-gathering stage, and gathering information doesn’t mean you’ll have to do anything with the kernel. Many newer Linux users protest the thought of working with the kernel. The kernel is the core of the operating system and is not immune to errors. It is, after all, software written by humans, for humans. Knowing the kernel version may expedite or confirm a solution.

The exact error message or symptom cannot be stressed enough. If you tell me that Mozilla doesn’t work, I will ask for clarification and any errors. Why not save time and state the problem in a way that puts the issue in focus. For instance, “Mozilla gives an error code 12227 when I visit Web page xyz, but it does not give an error when I visit Web page abc.” Notice the specific elements of this statement. There is an exact error, and the steps to reproduce the problem are included.

Where Are Solutions Found?

Now that you have detailed information relating to the problem, you can search for a solution. Linux users can find solutions by reading documentation, by searching the Web, or by posting questions for other support personnel or users to answer.

Documentation is a good source of information and is generally underutilized. When you are looking for answers to configuration or usability problems, consider reading any available documentation first. Readme files, user manuals, and FAQs all attempt to answer general questions and sometimes offer troubleshooting advice. Sources for documentation include the Linux distribution’s Web site, an application-specific Web site, or an online repository, such as The Linux Documentation Project at www.tldp.org or LinuxQuestions.org at www.linuxquestions.org.

For error messages, a Web search is a better alternative to searching through documentation sites. You have heard search advice before: try different keywords, change the word order, and use quotes to get better results. That is good advice when searching for general information, but not necessary when searching for an exact error message.

To illustrate the importance of recording and using the error message, a search for the phrase Mozilla doesn’t work. Even though the search words are matched in the search results, they are on a range of unrelated topics. Now search for Mozilla error 12227. These results are focused and provide a quick explanation of the error code.

Linux is an evolving operating system, and no one person can know everything or have the resources to figure out every problem. Help is available through support e-mail, application-specific mailing lists, or online forums, such as LinuxQuestions.org. The same advice holds for each of the aforementioned help lines. Ask a good question.

What Is a Good Question?

Anyone who spends any amount of time answering questions knows what a bad question is. For example, “I tried to install your software, but it won’t install. Can you help me?” There is no solution available to this question. The person answering could make a random guess at a solution, but that is not efficient.

According to Garcia, a good question starts with a descriptive subject. “On a busy site or mailing list, the first thing people will see is the title/subject. We’ll often see a title such as ‘help!!!’ This doesn’t give any indication what the question is about. People are less likely to even read an item with a title like this, let alone try to answer it.” Once you get the attention of somebody who can help, you are halfway there. Now you need to deliver the information the expert needs to answer your question.

Include the detailed information you recorded from the question: What information is needed? Garcia points out that a help request should also include attempted solutions. “It’s frustrating for a person who is trying to help to keep getting responses like ‘already tried that.’” The frustration is not limited to the person trying to help. The person seeking help will become frustrated because each “already tried that” response adds additional time - time that has passed without attempting a new solution.

How the help request is written is as important as what is included in the request. This is not English class, but an attempt to write in complete sentences and to use punctuation will increase the chance the reader of your request will understand what you are asking. Not being a proficient typist is not a reason to write in all caps or in all lowercase letters with no periods, nor is it a valid reason to respond to a set of instructions with the simple answer “didn’t work, now what.” State what didn’t work with the help and why you determined it didn’t work. Include error messages and observations. Follow-up responses demand the same thoroughness as the initial request.

What Skills Should a New Linux User Acquire?

When you think of acquiring skills in Linux, you immediately think of technical skills, such as system security or bash scripting. However, at the top of Garcia’s list of skills to acquire is patience. “A new user will inevitably run into a problem and it’s important they don’t just give up. Don’t get discouraged,” he added.

I would add that if you are getting discouraged, take a break from the problem and focus on something else for a day, an hour, or 15 minutes, depending on the nature of the problem and the urgency of finding a solution. Relax and allow yourself to process the information you have so far. Often the answer will come when you least expect it.

Conclusion

Problem solving is rarely an exact science. Often, users want an exact answer that solves a problem on the first try. The troubleshooting process is trial and error. There are too many factors involved to expect you will receive the “right” answer, right away. You, the user, can increase your chances of getting the right answer, right away by asking the right questions.

Originally posted by LinuxWorld Magazine in December 2004.