Linux System Administration Recipes A Problem-Solution Approach

C H A P T E R 11■ ■ ■Tracking Down BugsChances are you spend a fair amount of your working time in search of bugs. This chapter has somegeneral notes about best practices for finding and fixing bugs quickly, information about useful tools(diff, strace, and ltrace) when bug hunting, and a couple of recipes on how to improve your systemlogging (so you can locate problems faster) and use logging data.11-1. Saving TimeA sysadmin’s basic aim when faced with a bug report is to track the problem down and fix it as soon aspossible. Or, if fixing it will take a long time and the problem is urgent, you want to implement atemporary workaround.If you’re lucky, the person reporting the bug will have given you a good, clear description of exactlywhat they did, what is actually happening, and what they expected or wanted to happen instead. If youdon’t have this, then the first thing to do is to clarify these three things. You should do this with the userif at all possible or, if not, by experimenting yourself. Without a clear understanding of what the problemreally is, you’re at risk of wasting time—possibly a lot of time—finding and fixing something that maynot be the real problem. Unfortunately, users aren’t always good at explaining the issue immediately.We’ve all gotten those infuriating bug reports of the “X doesn’t work” variety.The following are good questions to ask when checking that you have a clear bug report:• What commands/situations trigger the bug?• What is the expected result?• What is the actual result?• Does it happen if you use a different machine? (This is particularly usefulinformation in situations where some directories are on NFS and users arecentralized.)• Does it happen if you log in as a different user? (You’ll probably have to findthis out yourself, because most users have only a single login.)• What have you and/or the user tried so far to fix it?213Download at WoweBook.Com