Autor: Alan J. Flavell Data: A: Exim users list Assumpte: Re: [exim] Re: sensitive data appearing in delay warning messages
On Tue, 19 Apr 2005, Philip Hazel wrote:
> I got the impression that what is being requested is an identifying
> error number for each error message that Exim generates. And a document
> that allows you to look up the number and find an explanation for the
> error. Back in the days when we were running IBM mainframes, the IBM
> software used to do this.
Ah, nostalgia. Did you meet the internationalized variant of that,
with the message codes and parameters in the program code, and an
external file for each language, containing the respective text?
Worked pretty well, in its terms.
I must admit that by comparison, the unix-ish habit of having random
messages emerging from unknown parts of the code without any chapter
or verse was real difficult to cope with.
Paint me "off topic" if you must, but I was considerably heartened
recently when asked to debug a problem, and found the following amount
of detail in the error log, e.g:
[2005/03/30 06:26:44, 0] smbd/server.c:sig_hup(384)
Got SIGHUP
[2005/03/30 06:26:44, 0] param/loadparm.c:service_ok(2163)
No path in service data - using /tmp
[2005/04/07 06:26:30, 0] smbd/server.c:sig_hup(384)
Got SIGHUP
[2005/04/07 06:26:30, 0] lib/fault.c:fault_report(38)
===============================================================
[2005/04/07 06:26:30, 0] lib/fault.c:fault_report(39)
INTERNAL ERROR: Signal 11 in pid 4144 (2.2.3a-14.2 for Debian)
Please read the file BUGS.txt in the distribution
[2005/04/07 06:26:30, 0] lib/fault.c:fault_report(41)
Something to really get one's debugging teeth into.
> Great in theory. In practice, the documentation is either
> out-of-date, or tells you something bland like "probable user
> error".
Oh, IBM were sometimes guilty of that, but MS have developed the
procedure into a fine(!) art. "Friendy" error messages - my foot!
I call them "Fiendly error messages" in local documentation...
[Sorry for the digression, but sometimes the safety valve has to
blow.]
> Maybe today, with web pages an wikis it would be
> better, as long as enough effort is put into maintaining it. But
> maintaining documentation is hard work, and I am an old cynic.
In recent years I've found problem solving to be incomparably
easier thanks to search engines. Feed in the appropriate snippet from
the error report and - far too often to be coincidence - the answer
comes right up amongst the first few hits.
