Troubleshooting software systems  (Page 2/4)

Logging output / log files

If the first basic checks don't yield any useful data, it's time to start looking at the the output of the program. Does it create any log files when it runs? If so, are any error messages kicked-out when you run it? Can the log setting be turned up?

If the script does not generate its own log files, it's time to start generating them on your own. Many tools have commandline options that will increase verbosity - use them in conjunction with trapping the output using tools like script and tee .

Script

One of the most useful tools to use when troubleshooting is script . From the man page for script : "Script makes a typescript of everything printed on your terminal". So, while it is running, everything you type and/or is displayed will also get recorded into a file set when you generate the script session. Such an output file could end up being invaluable to the support team for the product if you need to open a case, or to the developers of the tool if you need to create a Bug Report .

Tee

Another very useful tool is tee . The man page for tee is short, but gets right to the point: "read from standard input and write to standard output and files". In other words, if you pipe the tool you are running into tee , not only will it display on the screen, but it will be captured in the output file you have supplied as well.

For example, in addition to the following displaying the entire contents of the filesystem (that your user has permission to see) on screen, it will trap the output into a file called "filesystem.out" in your home directory: ls -R / | tee ~/filesystem.out

Effective searching

Google (or Bing, Yahoo, DuckDuckGo, etc) is your friend when trying to find answers to technical problems. After checking the man pages for a given tool (if they exist), always take any error messages found to Google and see what may be found thereon. For example, an error kicked-out by Apache Tomcat is likely to be documented just by searching the error string on Google - and probably from the official documentation / known issues / publicly-viewable bug reports (eg (External Link) ).

Effective searching is far more than "let me Google that for you" - it is knowing both what to look for and how to evaluate the results. Weak searching is easy: type in what you're looking for and hope . Like going to eBay and searching for "baseball card" - you'll get millions of results on just that query: not the most helpful thing in the world. Try "roger maris rookie baseball card", and your resultset drops to a manageable few dozen - those are results you can pick through effectively. Similarly, searching for "OutOfMemory" will yield millions of hits, whereas " bea weblogic outofmemory java error jvm 1.4 " may start to yield useful results in the top 2-5 links.

Becoming an Effective Searcher will translate over into a host of other arenas beyond mere troubleshooting: from finding photographs of an obscure HVAC part, to locating the best deals on travel, searching effectively is a skill that anyone can learn, hone, and benefit from in their daily lives.