[sf-lug] The Zen of Bug

[Rick Moen]

[Moving this bit back from private mail, with Alex's approval.  The "page" 
referenced is http://twiki.org/cgi-bin/view/Wikilearn/EmailServerSketches, 
especially the block diagrams.]


Quoting akleider at sonic.net (akleider at sonic.net):

> I've looked at the page:
> I think I'm at the next stage of development:
> I think I understand the inter-relationships but am lacking how to
> configure things.

Well, back starting in the late 1980s/early 90s when I dared to try to
operate full-service Unix Internet servers (first on BSD and then on
Linux), I screwed up configurations horribly.  And I did so repeatedly,
but then testing things and fooling with them until they worked.

I hate to sound like an old fogy, but really the essential step is to
just say "Screw it, I'm jumping in and getting my feet wet."

Backups are good.  ;->  You also end up either learning basic
troubleshooting (which is embarrassingly little more than just pure
logic and keeping of accurate records) or you die of frustration.

> Most linux programs are so hugely configurable (mail being probably the
> best example, it and the Xwindow system! not to mention the kernel itself)
> that a novice like me quickly looses sight of the forest for the trees!

Eh, you got that right!  Some *ix debugging commandments:

0   Honour thy backups.
1.  Burn not thy bridges.
2.  Thou shalt forbear to fix what is not broken, and shall endeavour 
    to learn from other people's mistakes in preference to your own.[1]
3.  Complex problems are often best solved by first breaking them into a
    equivalent set of separate, simpler problems.
4.  Thou shalt not change more than one variable at a time, and thou 
    shalt determine what are the possible suspects before changing anything.
5.  90% of *ix problems seem to involve ownership and/or permissions.  If
    something doesn't work for your username, but does for the root
    user, then it's _definitely_ ownership and/or permissions.
6.  Thou shalt carefully ignore data irrelevant to your situation.
    (I've seen many people try to read "dmesg | more" to determine,
    e.g., what device name to use for a CD/DVD drive and freak out from  
    information overload.  The trick is to know in advance that 
    dmesg data is very chatty and mostly irrelevant to your problem
    of the moment.)
7.  When debugging a GUI program's problems, notably its refusal to
    start up, do _not_ start it from a window manager's launcher.  
    Instead, open a terminal window and do, e.g., "oowriter &".
    (Why?  Because window manager launchers are notorious for throwing
    away a process's stderr aka standard error output, which you may
    need.)
8.  If you're stymied, maybe you forgot to look in its logfile?  For
    system daemons (including X11), they're usually muttering dark 
    things into somewhere under /var/log, that may make the answer 
    blindingly obvious.
9.  The "script" program is your friend.  (Do "man script".)


[1] Old joke:  "You can tell the pioneers in technology fields by the
arrows sticking out of their backs."  E.g., there are at least two ways
to find a good wireless chipset for Linux.  Both work.  One is to buy a
card at random, see if it works, and keep returning them and trying
again until one works.  Another is to benefit from others' experience.
Guess which is quicker and cheaper?  ;->