Mailing List Archive: Apache: Docs

error numbers

Index | Next | Previous | View Threaded

rbowen at rcbowen

Mar 8, 2012, 9:00 AM

Post #1 of 9 (308 views)
Permalink

error numbers

After agitating for error numbers, we haven't done much to document them. I'd like to start a discussion of where, and how, to document these.

At the moment, we have http://wiki.apache.org/httpd/Logs which is a decent start, but hasn't been touched in 2 years. This seems to be the right "where", but I'm not sure about the how.

There are over 2000 of these numbers so far, and I think having a page for each is probably overkill, although there are some that warrant more than a sentence of discussion.

Here's what I suggest.

One page, listing all of the AH*** error codes in a table with:

Error code
Module
Error message (template)
Extremely brief description
Possibly a link to a more detailed explanation, if warranted.

The more detailed explanations may be one-pagers, for the more complicated scenarios, or, in some cases, a page may contain more than one (related) error. (Possibly by module?)

I'd like to have this in the xhtml docs, eventually, but starting it in the Wiki seems the best way to get people to start to contribute. And someone mentioned at one point that they could easily script the initial doc. I don't remember who said that, but if you have something ready, that would be great. Meanwhile, if nobody steps up, I can script that up.

Any thoughts before I dive in and start working on this?

--
Rich Bowen
rbowen [at] rcbowen :: @rbowen
rbowen [at] apache

mathijssch at gmail

Mar 8, 2012, 10:29 AM

Post #2 of 9 (296 views)
Permalink

Re: error numbers [In reply to]

I have extracted some info from source that might be useful, somebody with
more awk/grep/perl fu then me can probably combine it into a sensible
format:

http://mathijs.info/files/errors.txt
http://mathijs.info/files/errortexts.txt (has some dodgy matches but at
least most strings are there)

On Thu, Mar 8, 2012 at 6:00 PM, Rich Bowen <rbowen [at] rcbowen> wrote:

> After agitating for error numbers, we haven't done much to document them.
> I'd like to start a discussion of where, and how, to document these.
>
> At the moment, we have http://wiki.apache.org/httpd/Logs which is a
> decent start, but hasn't been touched in 2 years. This seems to be the
> right "where", but I'm not sure about the how.
>
> There are over 2000 of these numbers so far, and I think having a page for
> each is probably overkill, although there are some that warrant more than a
> sentence of discussion.
>
> Here's what I suggest.
>
> One page, listing all of the AH*** error codes in a table with:
>
> Error code
> Module
> Error message (template)
> Extremely brief description
> Possibly a link to a more detailed explanation, if warranted.
>
> The more detailed explanations may be one-pagers, for the more complicated
> scenarios, or, in some cases, a page may contain more than one (related)
> error. (Possibly by module?)
>
> I'd like to have this in the xhtml docs, eventually, but starting it in
> the Wiki seems the best way to get people to start to contribute. And
> someone mentioned at one point that they could easily script the initial
> doc. I don't remember who said that, but if you have something ready, that
> would be great. Meanwhile, if nobody steps up, I can script that up.
>
> Any thoughts before I dive in and start working on this?
>
> --
> Rich Bowen
> rbowen [at] rcbowen :: @rbowen
> rbowen [at] apache
>
>
>
>
>
>
>

--
Gr,

Mathijs

isoma at jellybaby

Mar 8, 2012, 12:55 PM

Post #3 of 9 (296 views)
Permalink

Re: error numbers [In reply to]

On 8 Mar 2012, at 17:00, Rich Bowen wrote:

> I'd like to have this in the xhtml docs, eventually, but starting it in the Wiki seems the best way to get people to start to contribute. And someone mentioned at one point that they could easily script the initial doc. I don't remember who said that, but if you have something ready, that would be great. Meanwhile, if nobody steps up, I can script that up.
>
> Any thoughts before I dive in and start working on this?

This does cry out for at least some automation.
I have in mind an approach using either pycparser or clang to grab the error text and its context out of the C source. However, I haven't ever actually used either tool. If anyone else already has experience doing something like this, and time to take part, please speak up so I don't just do a worse job slower.

--
Tim Bannister – isoma [at] jellybaby

Attachments:

smime.p7s (4.29 KB)

DRuggeri at primary

Mar 8, 2012, 4:01 PM

Post #4 of 9 (294 views)
Permalink

Re: error numbers [In reply to]

On 3/8/2012 12:29 PM, Mathijs wrote:
> I have extracted some info from source that might be useful, somebody
> with more awk/grep/perl fu then me can probably combine it into a
> sensible format:
>
> http://mathijs.info/files/errors.txt
> http://mathijs.info/files/errortexts.txt (has some dodgy matches but
> at least most strings are there)

These come from source, but isn't it reasonable to assume that the user
got the error number and text when the compiled code threw the error
that is in the source code? I think the community would be better served
by providing supplemental documentation aside from the error string they
already received.

Something along the lines of:
ErrNo: 01961
Proxy is pointed to a backend that starts with scheme "https" but the
SSLProxyEngine has not been enabled. Enabled the SSLProxyEngine by
adding "SSLProxyEngine On" or change "https" to "http" in the
BalancerMember, RewriteRule, ProxyPass or ProxyPassMatch directive.

For a person who has seen the error before, the log entry itself is
succinct enough to be clear, but for someone who hasn't, this more
verbose description should help them zero in on what needs to be changed
for this to work right.

Am I on target with others' expectations? If so, maybe we should take
these two lists and start a catalog of what errors need more information
and which are sufficient as they are.

P.S.
I laughed out loud when I fatfingered the URL to one of those txt files :-)

--
Daniel Ruggeri

---------------------------------------------------------------------
To unsubscribe, e-mail: docs-unsubscribe [at] httpd
For additional commands, e-mail: docs-help [at] httpd

rbowen at rcbowen

Mar 8, 2012, 5:21 PM

Post #5 of 9 (291 views)
Permalink

Re: error numbers [In reply to]

On Mar 8, 2012, at 7:01 PM, Daniel Ruggeri wrote:

> On 3/8/2012 12:29 PM, Mathijs wrote:
>> I have extracted some info from source that might be useful, somebody
>> with more awk/grep/perl fu then me can probably combine it into a
>> sensible format:
>>
>> http://mathijs.info/files/errors.txt
>> http://mathijs.info/files/errortexts.txt (has some dodgy matches but
>> at least most strings are there)
>
> These come from source, but isn't it reasonable to assume that the user
> got the error number and text when the compiled code threw the error
> that is in the source code? I think the community would be better served
> by providing supplemental documentation aside from the error string they
> already received.
>
> Something along the lines of:
> ErrNo: 01961
> Proxy is pointed to a backend that starts with scheme "https" but the
> SSLProxyEngine has not been enabled. Enabled the SSLProxyEngine by
> adding "SSLProxyEngine On" or change "https" to "http" in the
> BalancerMember, RewriteRule, ProxyPass or ProxyPassMatch directive.
>
>

Yes, that is indeed the intent of this effort. The generated text files were merely a starting point from which to work.

> For a person who has seen the error before, the log entry itself is
> succinct enough to be clear, but for someone who hasn't, this more
> verbose description should help them zero in on what needs to be changed
> for this to work right.
>
>
> Am I on target with others' expectations? If so, maybe we should take
> these two lists and start a catalog of what errors need more information
> and which are sufficient as they are.

Yep

--
Rich Bowen
rbowen [at] rcbowen :: @rbowen
rbowen [at] apache

rainer.jung at kippdata

Mar 9, 2012, 5:16 AM

Post #6 of 9 (289 views)
Permalink

Re: error numbers [In reply to]

On 09.03.2012 02:21, Rich Bowen wrote:
>
> On Mar 8, 2012, at 7:01 PM, Daniel Ruggeri wrote:
>
>> On 3/8/2012 12:29 PM, Mathijs wrote:
>>> I have extracted some info from source that might be useful, somebody
>>> with more awk/grep/perl fu then me can probably combine it into a
>>> sensible format:
>>>
>>> http://mathijs.info/files/errors.txt
>>> http://mathijs.info/files/errortexts.txt (has some dodgy matches but
>>> at least most strings are there)
>>
>> These come from source, but isn't it reasonable to assume that the user
>> got the error number and text when the compiled code threw the error
>> that is in the source code? I think the community would be better served
>> by providing supplemental documentation aside from the error string they
>> already received.
>>
>> Something along the lines of:
>> ErrNo: 01961
>> Proxy is pointed to a backend that starts with scheme "https" but the
>> SSLProxyEngine has not been enabled. Enabled the SSLProxyEngine by
>> adding "SSLProxyEngine On" or change "https" to "http" in the
>> BalancerMember, RewriteRule, ProxyPass or ProxyPassMatch directive.
>>
>>
>
> Yes, that is indeed the intent of this effort. The generated text files
> were merely a starting point from which to work.
>
>
>> For a person who has seen the error before, the log entry itself is
>> succinct enough to be clear, but for someone who hasn't, this more
>> verbose description should help them zero in on what needs to be changed
>> for this to work right.
>>
>>
>> Am I on target with others' expectations? If so, maybe we should take
>> these two lists and start a catalog of what errors need more information
>> and which are sufficient as they are.
>
> Yep

AFAIR the log tags were motivated by Stefan in order to be able to
exactly identify a certain message, e.g. when doing a search on a search
engine. The plan is *not* to reduce to reduce the logging down to the
log tag and leave module name, message string and all the other nice
info out, because you could look it up in the docs.

The primary goal, finding traces of similar log errors in the net should
be satisfied by the tag itself. Using the tags as an index into a more
detailed description of log errors is fine, but we won't be able to do
it for most messages - there are to many.

I wonder whether such info would fit into the wiki?

Regards,

Rainer

---------------------------------------------------------------------
To unsubscribe, e-mail: docs-unsubscribe [at] httpd
For additional commands, e-mail: docs-help [at] httpd

rbowen at rcbowen

Mar 9, 2012, 6:10 AM

Post #7 of 9 (290 views)
Permalink

Re: error numbers [In reply to]

On Mar 9, 2012, at 8:16 AM, Rainer Jung wrote:

> AFAIR the log tags were motivated by Stefan in order to be able to exactly identify a certain message, e.g. when doing a search on a search engine. The plan is *not* to reduce to reduce the logging down to the log tag and leave module name, message string and all the other nice info out, because you could look it up in the docs.

Yes. There were many conversations that led to this. The one I remember was at ApacheCon, but I'm sure it's been discussed before.

Perhaps I misunderstood what Mathijs was saying? Anyways, my expectation is that the error message itself still remain useful, assuming you know what it means. The tag will then be something you'd Google for and find a more detailed explanation, in particular with a recipe of how to fix the problem.

>
> The primary goal, finding traces of similar log errors in the net should be satisfied by the tag itself. Using the tags as an index into a more detailed description of log errors is fine, but we won't be able to do it for most messages - there are to many.
>
> I wonder whether such info would fit into the wiki?

On the one hand, I don't agree that there are too many. There are no space limits on the Internet.

On the other hand, I don't expect that most of them will need any further detail. There's only one way to interpret "AH00128: File does not exist: /usr/local/apache2/htdocs/asdf", right? But the ones that require more explanation would have more than just the plain error message, but would have a more detailed explanation of what to do about it. Sort of what we already started doing on the wiki, but with a more useful lookup code.

--
Rich Bowen
rbowen [at] rcbowen :: @rbowen
rbowen [at] apache

mathijssch at gmail

Mar 9, 2012, 7:09 AM

Post #8 of 9 (286 views)
Permalink

Re: error numbers [In reply to]

On Fri, Mar 9, 2012 at 3:10 PM, Rich Bowen <rbowen [at] rcbowen> wrote:

>
> On Mar 9, 2012, at 8:16 AM, Rainer Jung wrote:
>
> AFAIR the log tags were motivated by Stefan in order to be able to exactly
> identify a certain message, e.g. when doing a search on a search engine.
> The plan is *not* to reduce to reduce the logging down to the log tag and
> leave module name, message string and all the other nice info out, because
> you could look it up in the docs.
>
>
>
> Yes. There were many conversations that led to this. The one I remember
> was at ApacheCon, but I'm sure it's been discussed before.
>
> Perhaps I misunderstood what Mathijs was saying? Anyways, my expectation
> is that the error message itself still remain useful, assuming you know
> what it means. The tag will then be something you'd Google for and find a
> more detailed explanation, in particular with a recipe of how to fix the
> problem.
>

It was indeed just a starting point, and the intention of such a list would
be that if a user google's for the AHxxxx code, he would arrive on our
wiki, where more explanation can be found (if thats needed). This can be a
simple explanation text, or a link to another article.

I have started a wiki page for this:
http://wiki.apache.org/httpd/ListOfErrors and will go over some of the odd
results such as empty messages.

The only thing I'm worried about here is about keeping this list up-to-date
with trunk.

>
>
> The primary goal, finding traces of similar log errors in the net should
> be satisfied by the tag itself. Using the tags as an index into a more
> detailed description of log errors is fine, but we won't be able to do it
> for most messages - there are to many.
>
> I wonder whether such info would fit into the wiki?
>
>
> On the one hand, I don't agree that there are too many. There are no space
> limits on the Internet.
>
> On the other hand, I don't expect that most of them will need any further
> detail. There's only one way to interpret "AH00128: File does not exist:
> /usr/local/apache2/htdocs/asdf", right? But the ones that require more
> explanation would have more than just the plain error message, but would
> have a more detailed explanation of what to do about it. Sort of what we
> already started doing on the wiki, but with a more useful lookup code.
>
> --
> Rich Bowen
> rbowen [at] rcbowen :: @rbowen
> rbowen [at] apache
>

sf at sfritsch

Mar 11, 2012, 7:20 AM

Post #9 of 9 (271 views)
Permalink

Re: error numbers [In reply to]

On Thu, 8 Mar 2012, Mathijs wrote:

> I have extracted some info from source that might be useful, somebody with
> more awk/grep/perl fu then me can probably combine it into a sensible
> format:
>
> http://mathijs.info/files/errors.txt
> http://mathijs.info/files/errortexts.txt (has some dodgy matches but at
> least most strings are there)

FTR, a "make update-log-tags" in the top-level source dir in trunk creates
a similar list in docs/log-message-tags/list. Because that file is easily
re-created, it is not committed to svn, though. The line numbers would
change way too often, anyway.

---------------------------------------------------------------------
To unsubscribe, e-mail: docs-unsubscribe [at] httpd
For additional commands, e-mail: docs-help [at] httpd

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads