Problem Solving

Probably one of the most difficult things to teach someone is experience. Knowing how to approach a problem, and what tools to use to fix it is something that is best learned by doing. There are, however, many concepts and ideas to keep in mind when tackling a dilemma. The following procedures can be used on many problems ranging from "I can't log in" to "hey, where did the Internet go!"

• Is There a Problem?
  When first approached with a problem you should not make any assumptions about it. If someone comes up to you and says they can't login, don't just assume that it is a user error. By the same token, don't assume that the passwd file is missing either. At this point, the only factual information you have to go on is that someone reported that they cannot login.

  If you make quick judgments, you may find yourself looking in the wrong place. While you are trying to find an older version of the passwd file, the user may simply need the Caps Lock key depressed. What you should be doing instead is getting more information about the problem. Is it just a user error? Is the Caps Lock key stuck? Did someone break in and post your passwd file to alt.2600?

• Reproduce the Problem
  One of the things you should always try to make sure you can do is reproduce the problem. If someone has trouble logging in, watch them do it. Make them try it more then once. This will give you a good change to observe what's happening and also to weed out problems like miss-typed passwords.

  Many times, you may want to be able to reproduce the error yourself, without the user in question. This way you can have more control over what is going on, and the user may be able to carry on about his business while you fix the problem. This will also allow you to bring the problem to others who may be able to fix it.

• Narrow Down the Problem
  A good beginning step is to discover the scope of your problem. For instance, if a user cannot log in to a workstation, see if they can log in to a workstation with a different environment (e.g. network, operating system, remote or local). The idea here is to narrow down the problem to a physical area. Perhaps the NIS server for a certain lab or subnet is down, or the user has a login rc file that doesn't work under a particular operating system.

  Next try to log in to the same machines with a different user (probably yourself, or some other user you are pretty sure should work). If you can log in, chances are there is something specific to the user. You now know that it is not a problem with the operating system or the specific machines.

  Finally, find out some history. Has the user ever logged in before? If so, when was the last successful login, and on what machine? This is especially helpful if you know of any changes that have happened since the last successful login. Perhaps a disk server has been moved, or a passwd server changed. From here, you can begin the tedious task of finding out exactly what is wrong, but you will have greatly narrowed down the scope of possible causes.

• Construction/Destruction
  Another good technique is something very similar to debugging code. The idea is to either build a very small set of circumstances that fail in the same manner as the problem you are trying to solve, or do the opposite; take the failing problem and work it down until it stops failing (or starts working correctly again).

  This is usually useful in automated processes, such as a cron job that isn't working. The constructionists would first test if cron is working by running a very simple cron job (perhaps one that just touches a file). The destructionist would begin simplifying the problem by removing more complicated parts of the script supposedly run by cron.

  Neither technique is necessarily better then the other. Sometimes one is more appropriate then the other in certain situations, but mostly it usually depends on the method that you prefer. It's similar to bottom-up and top-down programming.

• Be Mindful
  It's always helpful to be well informed. Know what's going on at your site. If the primary name server is going down for repairs, you should know when it will be down, when it will be back up, and what effects it will have. You should also know about common problems that may be specific to your site. Knowing your site has a particularly slow mail server will help you field questions of "why haven't I gotten my mail yet?"

• Chaotic Problems
  These are the most difficult problems to solve. The problems are not easily or noticeably reproducible and there doesn't appear to be an obvious reason why they occur. Windows95 is a good example here. Another example could be Linux occasionally locking up and displaying a stack trace.

  Sometimes, these types of problems are related to hardware. The CPU fan is failing, a SCSI-bus is not terminated properly, or the network is down.