"The Linux Gazette...making Linux just a little more fun!"

troubleshooting

From Matthew Easton on Wed, 06 May 1998

One thing I notice as I try to learn more about Linux, is that much of the information I come across is very specific to a particular situation or a particular piece of software. I'd like to get away from the 'step by step instructions for software x' and construct a "bag of tricks" that will allow me to solve problems myself.

To explain: In my job I troubleshoot Macintosh hardware and software. If you had a problem with a Mac I could tell you some things to check and several procedures to try-- and even if I was unfamiliar with the particular application that was failing you, chances are pretty good that things would be functioning in the end.

That is why we have professional technical support, system administration, help desk, repair technicians etc.

The issue is similar for a number of trades and professions.

Even the Mac for all its vaunted "easy of use" and consistency really requires a significant acculturation to a large number of assumptions. I know this from very recent first hand experience since I gave my mother her very first computer earlier this year --- it was a Mac Performa.

Granted the user interface is greatly simplified under Macintosh compared to Linux, but are there any general principles or things to look for, or standard procedures for troubleshooting software under Linux, or tools?

The simplicity of Macs and Windows can largely be summed up as:

If you don't see a menu option, button or dialog for it --- you probably can't do it.

(I realize this is a bit of an over simplication --- there are whole books of Mac and Windows "tricks" that are slowly gleaned over time).

These system make a reasonable subset of their functionality available on their face (through full-screen menu driven user interfaces). That whole issue of "icons" and "GUI's" is completely a red herring since they really are just menus under all the hype. I have a friend who said that the easiest system she'd ever worked on was an AS/400 (running OS/400 naturally enough). She described (even showed me, once) the interface and it did sound pretty handy.

Unix is usually described as a "toolbox." The analogy is reasonable. If I handed you a real box full of hammers, screwdrivers, nail guns, pliers, drills, saws, wrenches sockets, and similar physical tools it wouldn't help you build or rewire your house, fix your car or anything --- until you learned the appropriate construction and mechanical trades that use these tools.

Similarly we find that some programmers under Unix can be just as confused and incapacitated when faced with system or technical administrative issues as an auto mechanic might be when faced with a plumbing problem. Naturally a plumber or mechanic is more likely to successfully take on other "handyperson" repairs than someone with no related experience.

Another way of thinking about these OS' is in terms of culture and language. Natural language (including idiom) is entwined with many cultural assumptions. Unix/Linux conventions can be seen as a "language" for expressing demands of your computer (via the shell, through myriad configuration files, even in the Motif, KDE, OpenLook and other GUI's that we encounter).

The advantage of this "linguistic" point of view is that it approaches the level of complexity of a Unix system. When I was an electrician I doubt I encountered more than two hundred different tools, and probably less than two thousand different components (connectors, fittings, brackets, etc). (Thousands of sizes and minor differences --- but not different in terms of usage semantics).

On this Linux box if I switch to a bash shell prompt and double tap on the "Tab" key on a blank line (forcing it to try command completion) it warns me that I have over 2300 commands available to me. Many of these are full programming languages or environments like awk, perl, and emacs (elisp). Similarly I once determined that my copy of emacs (or was it xemacs) had about 1500 interactively accessible functions built into it. (If I installed the emacs 'calc' (a large mathematics package) that would probably double.

So there's quite a bit of depth and breadth available.

For example: How do I deal with a segmentation fault? Or, if an application installs broken and reinstalling the RPM package still does not work, is there a way to get Linux to tell me what is missing or corrupted? And what can I do about a program that (under X windows) briefly appears and then dies without error messages?

In many cases these can be tracked down using 'strace' (the system call tracer).

Any segmentation fault is a bug in the program (or corruption in its binaries or libraries). Robust programs should handle bad data, corrupted configuration files, etc, gracefully.

Packages that fail to operate as expected might be buggy, or they migh have inadequate documentation. I personally like to see programs that have some sort of "diagnostics" or "check option" to help me track down problems with them.

('sendmail' and 'named' are notable culprits in this case).

Thanks for any clarification on these or any other mysteries. . .
Matt Easton

That will take an entire book.

(Incidentally I found this message languishing in an old drafts folder and decided to finish it up and send it off. I really wanted to say much more on this topic --- but I decided to write a book instead.

Copyright © 1999, James T. Dennis
Published in The Linux Gazette Issue 36 January 1999

						a	b	c	1	2	3	4	5	6	7	9	10	11	12
						15	16	18	19	20	21	22	23	24	25	26	27	28
						29	31	32	33	34	35	36	37	38	39	40	41	42	44
45	46	47	48	49	50	51	52	53	54	55	56	57	60	61	62	63	64	65	66
67	69	72	76	77	78	79	80	81	82	84	85	86	87	91	94	95	96	97	98