Linux System Administration Recipes A Problem-Solution Approach

CHAPTER 11 ■ TRACKING DOWN BUGS■ Note You may have heard of the idea of “teddy bear programming.” There’s a story told in The Practice ofProgramming (among other places) of a university computing support department that had a teddy bear sitting bythe door. Students were allowed to take their problem to a human only if they’d already explained it to the bear. Itwas fairly common that the act of explaining the problem was sufficient to give the person doing the explaininganother idea to try or a realization of what might be going wrong. A similar thing sometimes occurs, in myexperience, when writing an e-mail to a mailing list and trying to describe the problem clearly and succinctly andanticipating possible queries. Explaining your problem to a co-worker can also work in the same way. Theimportant point is that the act of talking it through can help you come to a better understanding of what’s going on,or even to a solution.Once you have a clear understanding of the problem, the next thing to do is to try to narrow downthe problem space. Generate a test case from your initial bug report, and then shrink the test case downas far as you can while still demonstrating the problem. When your increasingly small test eventuallystops showing the problem, that’s more valuable information in tracking down the bug.You can also run your test case as another user, as root, as the same user on another machine, andas root or another user on another machine. All these tests will help establish a space where the problemmight be. It’s well worth running as many tests as you can before you start actually doing any work inchanging anything; otherwise, you won’t necessarily be able to tell what it is you did that fixed theproblem (see Chapter 1).If the machine you’re working on is a desktop machine, if the problem is a config or software-relatedone, and if it’s showing up only on this machine, consider how much time you’re prepared to spend ontrying to fix it. It’s good practice to have your desktops basically interchangeable and to have an installsetup that’s as straightforward and hands-off as you can possibly make it. My own rule of thumb is that ifsuch a problem is still unsolved after an hour, it’s time to kick off a reinstall. (All data partitions areindependent from all root and boot partitions in my work setup, so this doesn’t cause any dataproblems.) The exact amount of time may vary for you, but chances are, there’s a point at which itdoesn’t make much sense to keep throwing your time and energy at a problem that will often be fixed bya quick, clean reinstall. This may seem like a bit of a cheat (surely on Linux you should always be able tofind and fix a bug “properly”!), but sometimes cheating is the most pragmatic thing to do if your aim is tokeep your systems running and your users happy. An alternative, if you just can’t bear to cheat, is to havespare desktops around that you can switch in (so the user is happy) and keep the problem box in youroffice while you beat your head against the issue.■ Note Obviously, not all problems will be solved by this! Anything that’s showing up on multiple machines or foronly one user is probably not going to be fixed by a reinstall, at least not permanently.214Download at WoweBook.Com